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ABSTRACT 


Over  the  last  two  decades,  cockpits  have  migrated  from 
the  traditional  analog  gauges  of  moving  dials  to  computer 
displays  representing  an  assortment  of  flight  data.  To  keep 
in  stride  with  this  modernization  trend,  the  U.S.  Navy 
determined  that  the  newest  rotary-wing  fleet  aircraft,  the 
MH-60S  and  MH-60R,  would  incorporate  these  advanced  cockpit 
designs.  This  program  was  named  Common  Cockpit.  Using 
structured  interviews  with  current  Navy  MH-60S  pilots,  and 
analysis  of  system  design  models;  it  was  determined  that  the 
MH-60  glass  cockpit  has  fundamental  flaws  in  cockpit  design 
and  usability.  One  major  issue  identified  is  the  omission 
of  a  fully  integrated  moving  map.  The  lack  of  a  moving  map 
is  a  serious  issue  because  many  of  the  MH-60  missions 
require  precise  navigation.  The  Navy  pilots  interviewed 
indicated  that  lack  of  a  moving  map  makes  mission  task 
performance  difficult  and  could  threaten  safety.  It  is 
argued  here  that  a  user-centered  design  methodology  would 
have  given  ample  consideration  to  including  the  moving  map 
and  would  have  produced  a  more  effective  and  usable  cockpit 
design.  Recommendations  are  made  to  improve  design 
methodology  by  using  Crew-Centered  Design  methods. 
Recommendations  are  made  regarding  modification  of  existing 
Common  Cockpit  acquisitions  procedures  needed  to  produce  a 
better  product  for  the  fleet. 


v 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  PURPOSE . 1 

B.  BACKGROUND . 1 

C.  PROBLEM  DEFINITION . 3 

II.  A  REVIEW  OF  THE  MH-60S  AND  COMMON  COCKPIT  IN  RELATION 

TO  THE  ACQUISITIONS  PROCESS . 5 

A.  COMPUTER  EVOLUTION  AND  COCKPIT  INTEGRATION . 5 

B .  HELICOPTERS  AT  SEA . 5 

C.  MH-60S  PROGRAM . 7 

1 .  General  Description . 7 

2  .  Program  History . 8 

D.  THE  COMMON  COCKPIT . 15 

1 .  History . 15 

2 .  Description . 17 

III.  INTERVIEW  METHODOLOGY . 21 

A.  INTERVIEW  SUBJECTS  AND  PROCEDURES . 21 

B.  INTERVIEW  METHODOLOGY  RATIONAL . 22 

IV.  INTERVIEW  RESULTS  AND  DISCUSSION . 27 

A.  INTERVIEW  RESULTS  SUMMARY . 27 

B.  GENERAL  INTERVIEW  DISCUSSION . 28 

C.  SPECIFIC  DISCUSSION  ON  MOVING  MAPS . 29 

V.  MOVING  MAPS  AND  THE  COMMON  COCKPIT  DESIGN  METHODOLOGY  .  .31 

A.  MOVING  MAP  RATIONAL . 31 

1.  Moving  Maps . 31 

2.  Moving  Map  MH-60S  Implementation . 32 

3 .  Lockheed  Martin  Cockpit  Design  Methodology  ...  34 

a.  Lockheed  Martin  Process  Guidance  Series 

Systems  Engineering:  Human-Computer 

Interface  Requirements  (HCIRS)  Overview  .  35 

b.  Systems  Engineering  Process . 35 

c.  The  Iterative  Process . 36 

4.  Digital  Map  Kneeboard  (DMK) . 38 

a.  Digital  Map  System . 39 

b.  Pilots  Likes/Dislikes  and  Limitations  of 

Heads -down  Devices . 42 

c.  Planned  Obsolesce  of  the  DMK . 45 

B.  DESIGN  METHODOLOGY  FLAWS  AND  A  SUGGESTED  ALTERNATE 

DESIGN  METHODOLOGY . 46 

1.  Crew  Centered  Design  Philosophy . 48 


Vll 


2. 


Recommended  Changes  to  Lockheed  Martin  HCI 
Design  Methodology  Based  on  the  CCD 
Philosophy . 51 

a.  Use  of  Design  Methodology  Specifically 

Developed  for  Cockpit  Design . 51 

b.  Cost  Effectiveness  Must  be  Evaluated 

from  a  Holistic  Standpoint . 53 

c.  View  the  Cockpit  as  a  Sum  of  Its  Parts 

for  Design  Decisions . 53 

d.  Carefully  Consider  Incorporating 

Previous  Designs . 56 

VI.  CONCLUSIONS,  RECOMMENDATIONS  AND  FURTHER  STUDY . 59 

A.  CONCLUSION . 59 

B.  APPLYING  CREW  CENTERED  DESIGN . 59 

1 .  Functional  Requirements  Evaluated . 61 

2 .  Mapping  Options . 62 

a.  Ego-referenced  Frame . 63 

b.  World-referenced  Frame  .  65 

3.  2D/3D  Solution . 65 

a .  2D  Moving  Map . 66 

b.  3D  ERF  FLIR . 71 

4.  Symbology  and  Color  Scheme . 72 

C.  RECOMMENDATIONS . 73 

1.  Common  Cockpit  Recommendations . 73 

2.  Defense  Acquisitions  Recommendations . 74 

D.  FUTURE  WORK . 76 

APPENDIX  A:  INTERVIEW  RESULTS  SUMMARY . 79 

A.  SUMMARY  STATISTICS . 79 

B.  QUESTION  SUMMARIES . 79 

APPENDIX  B:  RAW  INTERVIEW  DATA . 83 

LIST  OF  REFERENCES . Ill 

INITIAL  DISTRIBUTION  LIST . 119 


viii 


LIST  OF  FIGURES 


Figure  1.  CH-46D  Sea  Knight  was  eventually  replaced  by 

the  MH-60S  (From:  [1]) . 6 

Figure  2.  MH-60S  Knighthawk  doing  VERTREP  duties  (From: 

[2]  ) . 7 

Figure  3.  The  Helo  Master  Plan  (From:  [3]) . 9 

Figure  4.  Original  Helo  Master  Plan  (From:  [4]) . 13 

Figure  5.  Revised  Helo  Master  Plan  based  on  the  CH-60 

acquisition  (From:  [4]) . 14 

Figure  6.  MH-60S  Block  I  Common  Cockpit  (From:  [5]) . 18 

Figure  7 .  PKI  /  FFK  located  in  the  lower  consol  area  of 

the  CC  (From:  [5]) . 19 

Figure  8.  Lockheed  Martin  Human  Computer  Interface 

Requirements  (HCIRS)  contents  (From:  [6]) . 36 

Figure  9.  Lockheed  Martin  eight  step  HCI  design  process 

(From :  [6]) . 37 

Figure  10.  DMS  (From:  [7]) . 40 

Figure  11.  Current  fleet  DMK.  Pen  included  for  size 

reference  only . 40 

Figure  12.  Current  fleet  DMK.  Pen  included  for  size 

reference  only . 41 

Figure  13.  DMK  Specifications  (After:  [8]) . 42 

Figure  14.  Cost  of  design  changes  as  a  function  of  time 

(From :  [9]) . 46 

Figure  15.  Systems  engineering  iterative  HCI  design 

process  (From  [10]) . 49 

Figure  16.  Inserting  the  Crew-Centered  Design  philosophy 

in  to  the  traditional  design  methodology  (From: 

[10]  ,  p.  9]  ) . 50 

Figure  17.  The  current  navigation  display  of  the  CC  (From: 

[11,  Keys  cockpit  interface  simulator]) . 58 

Figure  18.  Egocentric,  Exocentric  perspective,  and 

Exocentric  Plan-view  displays  (From:  [12]) . 64 

Figure  19.  A  progression  of  viewpoints  from  ERF  to  2D 

planar  view.  Exocentric  2D  side  view  is  on  the 
far  right  (After:  [13]) . 64 


IX 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


x 


LIST  OF  TABLES 


Table  1.  MH-60S  Characteristics  (From:  [14]) . 8 

Table  2.  Subject  summary  data . 22 

Table  3.  Mission  experience  among  interview  subjects. 

Subjects  are  often  familiar  with  more  than  one 

mission  area . 24 

Table  4.  In-person  informal  interview  attributes  (After: 

[15]  ) . 25 

Table  5.  Interruption  and  distraction  factors  (From: 

[16]  ) . 44 


xi 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


Xll 


LIST  OF  ACRONYMS  AND  ABBREVIATIONS 


2D  -  Two  Dimensional 
3D  -  Three  Dimensional 

AMCM  -  Airborne  Mine  Counter  Measures 

ASW  -  Anti  Submarine  Warfare 

CAAS  -  Common  Avionics  Architecture  System 

CC  -  Common  Cockpit 

CAN  -  Center  for  Naval  Analysis 

CCD  -  Crew  Centered  Design 

CSAR  -  Combat  Search  and  Rescue 

DMK  -  Digital  Map  Kneeboard 

DMLS  -  Digital  Map  Loading  System 

DoD  -  Department  of  Defense 

DoDAF  -  Department  of  Defense  Architecture  Framework 

ERF  -  Ego  Referenced  Framework 

FAM  -  Familiarization  Flight 

FFK  -  Fixed  Function  Key 

FLIR  -  Forward  Looking  Infrared 

FMC  -  Flight  Mission  Computer 

FRS  -  Fleet  Replacement  Squadron 

GATM  -  Global  Air  Traffic  Management 

GOTS  -  Government  Off  The  Shelf 

HAC  -  Helicopter  Aircraft  Commander 

HCI  -  Human  Computer  Interaction 

HCU  -  Hand  Control  Unit 

HSC  -  Helicopter  Sea  Combat 

HUD  -  Heads  Up  Display 

ICS  -  Internal  Communications  System 

IRAD  -  Independent  Research  and  Development 

LAMPS  -  Light  Airborne  Multipurpose  System 

LOG  -  Logistics 


Xlll 


MC  -  Mission  Computer 
MEDEVAC  -  Medical  Evacuation 
MFD  -  Multi-Function  Display 
MLR  -  Medium  List  Replacement 
MS I I  -  Milestone  II 

NAVAIR  -  Naval  Air  Systems  Command 

NSW  -  Naval  Special  Warfare 

NTDS  -  Naval  Tactical  Display  Symbols 

NVD  -  Night  Vision  Device 

ORD  -  Operational  Requirements  Document 

OSD  -  Office  of  the  Sectary  of  Defense 

PKI  -  Programmable  Key  Interface 

R&D  -  Research  and  Development 

SAR  -  Search  and  Rescue 

SPECOPS  -  Special  Operations 

USN  -  United  States  Navy 

USNR  -  United  States  Naval  Reserve 

VBSS  -  Visit,  Board,  Search  and  Seizure 

VERTREP  -  Vertical  Replenishment 

WRF  -  World  Referenced  Framework 


xiv 


ACKNOWLEDGMENTS 


I'd  like  to  acknowledge  several  people  who  were 
instrumental  to  getting  this  thing  put  to  bed. 

Hats  off  to  Dr.  Jean-Francios  D'Arcy  and  Christine 
Collins  at  Lockheed  Martin,  who  were  a  wealth  of  both 
documentation  and  answers.  Chris'  information  and 

recommendations  were  spot-on  every  time! 

I'd  like  to  offer  a  hearty  salute  to  CDR  Spencer 
Crispell,  CDR  Wade  McConvey,  LCDR  Scott  Stringer  and 
especially  CDR  Mike  Harman  at  NAVAIR  for  all  the  source 
documentation  ranging  from  initial  acquisitions  items  to 
technical  information.  Without  support  from  NAVAIR,  this 
vital  information  would  be  impossible  to  come  by. 

Of  course,  I'd  like  to  thank  Dr.  Tony  Ciavarelli  and 
Dr.  Rudy  Darken,  my  advisors,  for  keeping  me  on  the  straight 
and  narrow.  Your  input  was  always  on  target  and  kept  it  all 
relevant . 

A  big  thanks  to  Janice  Rivera  and  Pam  Silva,  my 
personal  thesis  formatters!  Not  once  did  they  make  fun  of 
my  poor  grammar  and  complete  disregard  for  proper 
punctuation.  This  is  no  small  feat. 

Last,  and  certainly  not  least,  I'd  like  to  thank  my 
family:  Noelle,  Diana,  and  Alexandra.  All  those  great 

promises  about  NPS  being  a  great  opportunity  to  spend  time 
with  the  family  were  not  even  close!  You  guys  weathered 
through  my  frequent  absenteeism  and  always  supported  me 
100%!  I  am  truly  blessed. 


xv 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


xvi 


I .  INTRODUCTION 


A.  PURPOSE 

This  thesis  will  accomplish  three  fundamental  tasks: 

•  Using  structured  interview  methods,  usability 
engineering  techniques  and  the  author's  personal 
expertise,  determine  if  there  are  any  existing 
design  or  usability  issues  with  the  MH-60S  Common 
Cockpit 

•  In  regard  to  these  existing  design  issues,  review 
the  methodology  under  which  the  design  was  created 
and  recommend  a  different  or  modified  methodology 
that  would  create  a  better  design.  Using  this 
recommended  design  methodology,  present  a 
description  of  one  potential  design  improvement. 

•  In  the  scope  of  the  Common  Cockpit  acquisitions 
process,  recommend  changes  to  said  process  that 
would  enable  a  better  cockpit  to  be  designed  and 
acquired. 

B .  BACKGROUND 

The  author' s  first  experience  with  piloting  an  aircraft 
came  formally  in  the  spring  of  1994.  It  was  at  Whiting 
Field,  Pensacola,  Florida,  where  he  was  first  introduced  to 
the  complexities  and  challenges  of  piloting  an  aircraft. 
Following  the  standard  training  track,  he  started  with  the 
basic  single-engine  turbo-prop  T-34.  Following  the  fleet 
helicopter  replacement  pipeline,  he  then  flew  the  basic 
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helicopter  trainer,  the  TH-57 .  Basic  flight  training  was 
followed  by  training  and  operational  missions  in  the  fleet 
helicopter  H-46D  Seaknight,  where  he  accrued  almost  1,000 
flight  hours.  This  tour  was  followed  by  extensive 
experience  in  two  more  fleet  aircraft:  the  H-3  Sea  King 
helicopter  and  the  twin-engine  fixed-wing  utility  transport 
C-12B  Huron.  His  most  recent  tour  was  in  yet  another  fleet 
helicopter,  the  MH-60S  Knighthawk. 

Unique  to  the  Knighthawk  and  a  substantial  departure 
from  previous  aircraft  was  the  use  of  an  all-digital  "glass" 
cockpit.  Simply  put,  the  traditional  analog  dials,  gauges 
and  switches  of  the  previous  generation  of  aircraft  have 
been  replaced  with  four  LCD  monitors  and  a  host  of  keypads 
and  other  more  "computer  interface"  oriented  input  devices. 

To  the  author,  the  potential  of  this  transition  was 
exciting.  Having  seen  computers  explosively  grow  in  both 
functionality  and  usability  since  first  being  exposed  to  the 
Radio  Shack  TRS-80  and  Commodore  64  in  the  mid-1980s,  the 
author  assumed  that  a  21st  century  cockpit  must  have  the 
functionality  of  any  top  computing  system  and  the  usability 
of  the  sleekest  operating  system.  He  imagined  a  cockpit 
where  the  feel  was  more  like  the  bridge  of  the  Starship 
Enterprise  than  the  cockpits  of  the  previous  generation  of 
aircraft  he  had  flown.  The  expectation  was  that  everything 
was  configurable,  selectable,  scalable,  and  absolutely  user- 
friendly.  Those  lofty  expectations  were  not  quite  met. 

The  author  encountered  a  cockpit  that  did  indeed  have 
some  of  these  features,  but  in  many  aspects  seemed  lacking. 
To  the  author  and  his  fellow  squadron  pilots,  there  seemed 
to  be  something  fundamentally  lacking  in  the  usability  of 
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the  cockpit  itself.  Too  often,  particularly  with  new 
pilots,  the  cockpit  seemed  a  jumbled  collection  of  buttons 
and  computer  menus.  It  was  clear  that  usability  had  taken  a 
back  seat  to  functionality  during  design.  How  could  this 
have  happened  in  the  Navy's  newest  cockpit? 

Following  his  tour  in  the  Knighthawk,  the  author  opted 
to  explore  the  science  behind  the  computers  that  drove  that 
cockpit.  While  studying  Computer  Science  at  the  Naval 
Postgraduate  School,  he  was  exposed  to  the  concepts  of  Human 
Computer  Interfaces.  Armed  with  knowledge,  he  arrived  at 
the  purpose  of  this  thesis. 

C .  PROBLEM  DEFINITION 

Based  on  informal  user  interviews  and  personal 
experience,  the  MH-60S  cockpit  has  fundamental  user  design 
and  usability  issues  that  potentially  impact  mission 
accomplishment.  The  question  is  thus:  Will  the  use  of  a 
more  Human  Systems  Integration  (HSI)  oriented  design 
methodology,  applied  to  the  same  functional  requirements  as 
outlined  in  MH-60S  Operational  Requirements  Document  (ORD) , 
produce  a  more  usable  result? 

Also,  can  this  design  methodology  be  applied  throughout 
the  acquisitions  process  in  order  to  not  only  enhance 
cockpit  usability  but  all  human-machine  usability? 
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II.  A  REVIEW  OF  THE  MH-60S  AND  COMMON  COCKPIT 
IN  RELATION  TO  THE  ACQUISITIONS  PROCESS 


A.  COMPUTER  EVOLUTION  AND  COCKPIT  INTEGRATION 

The  last  20  years  of  aircraft  design  and  development 
has  seen  a  revolution  of  sorts.  As  computers  emerged  from 
the  large  units,  common  in  the  1950s,  to  the  sleek,  light 
and  low-power  units  of  today,  they  have  also  slowly  made 
their  way  into  the  aircraft.  Today's  modern  computer- 
integrated  or  "glass"  cockpits  almost  resemble  a  computer 
work  station  more  than  a  traditional  cockpit. 

B.  HELICOPTERS  AT  SEA 

Of  military  fleets  in  the  world,  the  need  to  conduct 
sustained  operations  at  sea  is  the  backbone  of  power 
projection.  In  this  effort  of  sustainment,  logistics  is  the 
key.  Fleet  logistics  is,  of  course,  a  little  more 
complicated  than  traditional  land  logistics  since  everything 
has  to  be  delivered  to  ships,  which  prefer  to  be  at  sea. 
One  method  of  doing  this  is  via  a  delivery  technique  called 
Vertical  Replenishment  (VERTREP) .  This  supply  delivery 
procedure  involves  transferring  goods  and  people  from  one 
ship  to  another,  shore  to  ship  or  ship  to  shore,  by  either 
attaching  an  external  load  to  a  helicopter  or  via  an 
internal  transfer.  For  years,  this  mission  was  filled  by 
the  versatile  H-46D  Sea  Knight  (Figure  1) . 
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Figure  1.  CH-46D  Sea  Knight  was  eventually  replaced  by 

the  MH-60S  (From:  [1] ) . 

Although  the  aircraft  was  initially  intended  as  a 
logistics  platform,  as  time  progressed  and  the  needs  of  the 
fleet  became  more  varied,  the  Sea  Knight's  mission  set 
expanded  to  include  Search  and  Rescue  (SAR) ,  Visit  Board 
Search  and  Seizure  (VBSS)  and  some  limited  Special 
Operations  (SPECOPS) . 

By  the  early  1990s,  two  things  quickly  became  readily 
apparent  to  Navy  planners :  the  Sea  Knight  was  rapidly 
exceeding  its  life  expectancy,  and  the  continued  growth  of 
mission  sets  was  pushing  the  limits  of  the  airframe.  It  was 
time  for  a  replacement.  The  answer  came  in  the  form  of  the 
Sikorsky  MH-60S  (Figure  2) . 
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Figure  2.  MH-60S  Knighthawk  doing  VERTREP  duties  (From: 

[2]). 

C.  MH-60S  PROGRAM 

1 .  General  Description 

The  MH-60S  is  an  all-weather  multi-mission  helicopter 
built  as  an  amalgam  of  UH-60  Blackhawk  and  SH-60  Seahawk 
components.  First  deployed  in  January  2003,  the  MH-60 
Knighthawk  is  designed  to  conduct  a  varied  mission  suite 
including  Airborne  Mine  Countermeasures  (AMCM) ,  Logistics 
(LOG)  and  a  more  aggressive  mission  known  as  Combat  Search 
and  Rescue  (CSAR,  also  known  as  Armed  Helo  or  AH)  [14]. 
Characteristics  are  summarized  in  Table  1. 
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Dimensions: 

Main  Rotor  Diameter 

16.36m 

Tail  Rotor  Diameter 

3.35m 

Overall  Length  With  Rotors 
Turning 

19.76m 

Height  to  Top  of  Turning 

Tail  Rotor 

5.13m 

Height  to  Top  of  Rotor 

Head 

3.76m 

Length  of  Fuselage 

15.26m 

Cabin  Volume 

11. 6  m  3 

Engines: 

Type 

2  x  GE  T7DQ-GE-4D1C  turboshaft  engines 

Take-Off  Rating 

1,26QkW  each 

Performance: 

Maximum  Cruise  Speed 

263  km/h 

Never-Exceed  Speed 

333km/h 

Table  1.  MH-60S  Characteristics  (From:  [14]) . 

2 .  Program  History 

The  MH-60S  was  born  out  of  a  recognized  need  in  the 
early  1990s  to  replace  several  aging  helicopter  platforms. 
By  the  end  of  the  cold  war,  the  Navy  was  operating  eight 
types  of  helicopters  [17].  All  were  specialized  for 
different  missions,  including  Vertical  Replenishment 
(VERTREP)  and  logistics  (LOG) ,  Anti-submarine  Warfare  (ASW) , 
Combat  Search  and  Rescue  (CSAR)  and  Naval  Special  Warfare 
(NSW)  [4] .  Of  the  fleet  helicopters,  the  H-1N,  H-3  and  H-46 
and  HH-60H  were  either  very  near  or  approaching  the  end  of 
their  service  lives  [18] . 

Conventional  naval  rotary-wing  aviation  urban  legend 
holds  that  around  this  time,  seeing  an  opportunity  to  reduce 
operating  costs  and  increase  mission  flexibility,  the  Navy 
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initiated  a  program  that  would  pare  down  the  existing 
diverse  helicopter  fleet  to  just  two  variants  of  the 
Sikorsky  H-60  (Figure  3)  .  As  this  section  will  chronicle, 
this  simple  interpretation  of  history  is  not  quite  the  case. 


HELO  MASTER  PLAN 
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Figure  3 . 


The  Helo  Master  Plan  (From:  [3] ) . 


The  CH-60,  as  the  MH-60S  was  originally  known,  had  it 
roots  in  the  late  1980s  and  early  1990s  discussions 
revolving  around  the  Marine  Corps  vertical  Medium  Lift 
Replacement  (MLR)  project  [19]  .  At  the  time,  the  Marine 
Corps  was  funding  the  development  of  the  Boeing  MV-22  medium 
lift  tilt  rotor  to  replace  its  aging  CH-46E  medium  lift 
helicopter  fleet.  While  Secretary  of  Defense  under 

President  George  H.W.  Bush,  Mr.  Dick  Cheney  attempted  to 
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terminate  the  V-22  program  due  to  cost  overruns.  His 
solution  to  the  MLR  was  the  Sikorsky  CH-60  [19]  . 

After  a  protracted  battle,  the  Marine  Corps  eventually 
won  and  continued  its  plan  to  acquire  the  MV-22.  Sikorsky, 
however,  continued  to  shop  its  CH-60  to  all  four  services 
[20]  .  In  specific  reference  to  the  Navy  portion  of  the 
Sikorsky  proposal.  Inside  the  Army  writes: 

As  for  the  Navy,  Sikorsky  contends  the  service's 
fleet  support  helicopter  assets  "are  aging  and 
experiencing  accelerated  attrition."  The  Navy  has 
some  recapitalization  plans  in  place  --  such  as 
an  upgrade  to  its  fleet  of  CH-46s  and  procurement 
of  a  new  helicopter  beginning  in  FY-98  --  but 
Sikorsky  anticipates  an  upcoming  cost  and 
operational  effectiveness  analysis  will  "have 
difficulty  dealing  with  the  cost  effectiveness" 
of  them.  [20] 

Inside  the  Army  continues: 

Some  observers  theorize  that  the  Sikorsky 
proposal  is  merely  an  effort  to  stave  off  a  halt 
in  the  Black  Hawk  production  line  should  the 
Office  of  the  Secretary  of  Defense  not  give  the 
Army  additional  money  for  Black  Hawk  procurement 
in  FY-97.  [20] 

By  1996,  Sikorsky  had  grown  desperate  to  push  the  CH-60 
multi-service  program,  or  at  the  very  least  extend  the 
manufacture  of  Army  UH-60  Black  Hawk  program  [21]  .  They 
felt  their  life  depended  on  it: 

There  is  trouble  down  the  road  [for  Sikorsky],  a 
company  official  said  last  week.  "Without  Black 
Hawk  procurement,  it  would  be  difficult  for 
Sikorsky  to  continue  as  a  company."  He  added  that 
Black  Hawk  procurement  could  total  as  much  as 
$1.1  billion  over  the  next  five  years.  "And 
right  now  Sea  Hawk  production  has  stopped  and  the 
CH-53  procurement  is  not  significant,  "  he 
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continued,  "and  there  really  is  no  future  program 
except  the  [SH-60R]  .  .  .  so,  no,  there's  not  a 
lot  of  business  right  now  for  Sikorsky.  The 
draft  briefing  charts  prepared  by  the  Program 
Analysis  and  Evaluation  shop  state  flatly  that 
the  'Cancellation  of  UH-60  buys  may  affect 
Sikorsky's  survival,  and  has  cost  implications 
for  the  Army's  RAH- 6 6  Comanche.'  [21] 

The  Army  had  originally  planned  to  buy  36  Black  Hawk 
helicopters  per  year  during  fiscal  years  1998-2003  but  had 
shifted  these  monies  to  other  priorities  [21]. 

This  mess  quickly  drew  in  the  Marine  Corps  again,  this 
time  in  their  effort  to  update  the  UH-1N.  The  original 
Marine  plan  was  to  update  both  the  UH-1  and  AH-1  to  the  N 
and  W  models,  respectively.  This  upgrade  would  leverage  an 
already  existing  training  and  supply  system  while  upgrading 
the  cockpits  and  engine/rotor  combination  [22].  The  Office 
of  the  Sectary  of  Defense  (OSD),  headed  by  Mr.  William 
Perry,  however,  wanted  to  keep  the  Sikorsky  production  lines 
open  and  continued  to  push  the  CH-60  as  an  alternative  to 
the  UH-1. 

Angered  by  the  Army's  move  to  halt  UH-60  Black  Hawk 
production,  the  OSD  drafted  a  plan  to  take  the  almost  $1 
billion  originally  scheduled  for  the  UH-60  and  give  it  to 
the  Navy  or  Marine  Corps  to  fund  the  CH-60,  a  predominately 
Black  Hawk  variant.  The  Marines  balked  yet  again, 
preferring  to  stick  with  their  original  upgrade  plans  for 
the  Cobra  and  Huey  [23] . 

The  Navy,  however,  saw  an  opportunity  to  solve  several 
of  their  helicopter  problems  with  one  solution.  Starting  in 
1995,  the  Navy  starting  drafting  the  "Navy  Helo  Master  Plan" 
(HMP)  [4]  .  The  HMP  morphed  out  of  a  Center  for  Naval 
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Analysis  (CNA)  study  that  looked  at  the  Navy's  helicopter 
force  structure  and  what  would  be  required  to  transition  to 
the  future.  The  initial  HMP  roadmap  didn't  include  the  CH- 
60  (Figure  4)  but,  once  word  of  a  potential  "free"  Black 
Hawk  variant  was  out,  the  plan  was  quickly  revised  (Figure 
5) .  The  H-60B/F  airframe  that  was  currently  in  use  was  not 
considered  since  that  particular  production  line  had  already 
been  shuttered.  The  replacement  for  the  H-60B/F,  named  the 
MH-60R  was  also  not  considered  since  that  production  line 
wasn't  scheduled  to  start  running  until  early  in  first 
decade  of  2000  and  would  do  nothing  to  keep  the  Blackhawk 
line  open.  This  move  to  "give"  the  Navy  a  "free"  airframe 
virtually  locked  in  the  CH-60  as  the  helicopter  of  choice 
for  the  Navy  since  the  entire  Navy  helicopter  roadmap 
depended  on  it  [24]  . 
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Figure  4 . 


Original  Helo  Master  Plan  (From:  [4]) . 
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Figure  5.  Revised  Helo  Master  Plan  based  on  the  CH-60 

acquisition  (From:  [4]) . 


The  HMP  momentum  resulted  in  a  sole  source  Request  For 
Proposal  (RFP)  for  Sikorsky  being  issued  in  1996  [24]  .  In 
fiscal  year  (FY)  1997,  Congress  directed  Sikorsky  Aircraft 
(SAC)  to  produce  a  demonstration  aircraft  [25] .  This 
Operational  Assessment  (OA)  demonstrator  was  a  combination 
of  the  existing  UH-60L  Blackhawk  airframe  with  H-60  Seahawk 
components  [26]  .  Between  November  1997  and  January  1998,  a 
successful  Operational  Assessment  (OA)  directed  by 
Commander,  Operational  Test  and  Evaluation  Force  (COTF)  was 
conducted  [25] .  This  success  led  to  the  program  receiving  a 
Mile  Stone  II  (MSII)  (Milestone  B  equivalent) /Low  Rate 
Initial  Production  (LRIP)  go-ahead  decision  in  July  1998  and 
Sikorsky  being  named  as  the  sole  source  contractor  on 
October  6,  1998.  The  contract  was  under  the  existing  U.S. 
Army  Aviation  &  Missile  Command,  Redstone  Arsenal  as  the 
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contracting  activity  [27].  It  should  be  noted  that  during 
the  OA,  "Neither  approved  nor  signature-ready  ORD 
(Operational  Requirements  Document)  or  TEMP  (Test  and 
Evaluation  Master  Plan)  documents  were  available  during  the 
November  1997-January  1998  OA  period"  [28,  p.  2]  and  draft 
documents  were  used  as  a  guideline. 

Designated  an  Acquisitions  Category  IC  (ACAT  IC) 
program  by  the  Under  Sectary  of  Defense  for  Acquisition, 
Technology  &  Logistics  (USD(AT&L))  in  July  of  1998  [25],  the 

program  quickly  ramped  up.  The  all  new  production  CH-60S 
first  flight  followed  in  January  2000  [14],  [29].  The  CH- 

60S  was  quickly  re-designated  the  MH-60S  to  reflect  the 
multi-mission  capability  of  the  airframe  [14].  Three 
distinct  mission  sets  were  designed  in  and  called  "blocks". 
Block  I  reflected  the  general  logistics  mission,  block  II 
was  modified  to  conduct  Airborne  Mine  Countermeasures  (AMCM) 
and  block  III  incorporated  the  more  offense  Armed  Helo  (AH) 
mission  kits  [7].  By  FY  2008,  132  airframes  had  either  been 
ordered  or  fielded  to  Navy  squadrons.  The  current  plans 
call  for  a  total  of  237  [14] . 

D.  THE  COMMON  COCKPIT 

1.  History 

As  the  new  CH-60  started  production  and  the  planned  MH- 
60R  (scheduled  for  production  in  2000  [21]  firmed  up,  the 

Navy  decided  to  make  the  technological  leap  to  an  all 
digital,  or  "glass,"  cockpit  display  for  both  the  MH-60S  and 
MH-60R  helicopters.  This  cockpit,  designed  for  use  on  both 
airframes  to  enhance  commonality  [29]  ,  was  named  the  Common 

Cockpit  (CC) .  At  this  point,  the  CC  was  notional  and  lacked 
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any  specific  ORD  type  document  of  its  own.  At  this  point 
the  MH-60R  was  the  more  mature  of  the  two  programs  and  thus 
it  can  be  concluded  that  initial  efforts  for  the  CC  were 
applied  toward  MH-60R  functional  requirements. 

Initially  included  as  part  of  the  MH-60S  Operational 
Requirements  Document  (ORD)  [30]  as  well  as  the  MH-60R  ORD, 
the  CC  was  spun-off  as  an  "845"  contact  prior  to  2002  [31]  . 
An  845  contract  referrers  to  "10  U.S.C.  2371,  Section  845, 
Authority  to  Carry  Out  Certain  Prototype  Projects."  [32] 
Per  the  OT  Guide: 

Other  "Transactions"  for  prototype  projects  are 
acquisition  instruments  that  generally  are  not 
subject  to  the  federal  laws  and  regulations 
governing  procurement  contracts.  As  such,  they 
are  not  required  to  comply  with  the  Federal 
Acquisition  Regulation  (FAR) ,  its  supplements,  or 
laws  that  are  limited  in  applicability  to 
procurement  contracts.  [32,  p.  8] 

Due  to  its  designation  as  an  845  program,  funding, 
particularly  Research  and  Development  (R&D)  costs,  are 
difficult  to  define.  According  to  [33],  Lockheed  Martin  was 
awarded  a  $423  million  contract  to  produce  common  cockpits 
for  the  MH-60S  and  MH-60R.  This  amount,  however,  may  not 
include  R&D  costs,  since  this  is  a  production  (APN-1) 
contract  and  usually  does  not  include  research  and 
development  costs.  For  certain,  prior  to  the  contract 
award,  $70.53  million  had  been  spent,  at  least  in  part,  on 
R&D  [34] .  Other  R&D  costs  may  be  included  in  the  Sierra  and 
Romeo  development  costs  but  are  not  clearly  defined  [35] . 

CC  requirements  are  also  scattered  throughout  the 
Sierra  and  Romeo  ORDs  and  hard  to  concisely  determine.  As 
an  initially  cobbled-together  program,  the  CC  currently 
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lacks  a  clearly  defined  requirements  document  such  as  the 
MH-60S  ORD.  As  of  this  writing,  however,  there  is  a  push  to 
formalize  these  requirements  [35] ,  [36] . 

2 .  Description 

The  Common  Cockpit  (Figure  6)  is  made  up  of  several 
components  including  Multi-Function  Displays  (MFD) ,  Fixed- 
Function  Keys  (FFK)  (Figure  7)  and  Programmable  Key 
Interface  (PKI) . 
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Figure  6 . 


MH-60S  Block  I  Common  Cockpit  (From:  [5] ) . 
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Figure  7 .  PKI  /  FFK  located  in  the  lower  consol  area  of 

the  CC  (From:  [5] ) . 


According  to  [14] : 

The  CC  includes  four  8in  x  lOin  active  matrix 
liquid  crystal  displays  and  dual  programmable 
operator  keysets.  The  avionics  includes  dual 
flight  management  computers  and  an  audio 
management  computer.  The  navigation  suite 
includes  a  Northrop  Grumman  (Litton)  LN-100G  dual 
embedded  global  positioning  system  and  inertial 
navigation  system. 
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III.  INTERVIEW  METHODOLOGY 


Based  on  an  in-depth  knowledge  of  the  subjects  by  the 
author,  himself  an  experienced  U.S.  Navy  pilot,  a  structured 
interview  method  was  chosen  to  obtain  needed  U.S.  Navy  Fleet 
pilot  inputs  on  the  MH-60  design.  The  interview  method 
selected  is  based  on  several  considerations  as  described  in 
[15,  p.  9]  and  elaborated  below.  Interview  data  is 
summarized  in  Appendix  A.  Raw  interview  data  is  found  in 
Appendix  B . 

A.  INTERVIEW  SUBJECTS  AND  PROCEDURES 

Nine  subjects  were  interviewed  over  a  three-day  period 
from  October  27,  2008,  to  October  29,  2008.  Subjects  were 
all  pilots  from  the  MH-60S  West  Coast  Fleet  Replacement 
Squadron,  Helicopter  Sea  Combat  Squadron  11  stationed  at 
Naval  Air  Station,  North  Island,  San  Diego,  California. 
Eight  of  the  subjects  were  instructor  pilots  and  one  was  a 
student  pilot  nearing  the  end  of  the  training  syllabus. 
Pilot  experience  is  summarized  in  Table  2.  Of  nine  subjects 
interviewed  two  were  qualified  Helicopter  Aircraft  Commander 
(HAC)  in  a  different  aircraft  model.  Table  2  summarizes 
subject  flight  hour  and  experience  levels. 
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Total 

Flight 

Hours 

Total  MH- 
60S  Flight 
Hours 

Qualified 
HAC  in 
Different 
Aircraft 

1200 

30 

Yes 

1200 

1000 

No 

1370 

250 

Yes 

1300 

1000 

No 

1450 

1200 

No 

275 

100 

No 

1550 

1350 

No 

1250 

1000 

No 

1300 

900 

No 

Table  2.  Subject  summary  data. 


Interviews  were  conducted  in  a  HSC-11  briefing  room 
well  known  to  all  nine  subjects.  All  interviews  were 
conducted  during  normal  working  hours  (0800-1500) . 
Questions  were  formulated  by  the  author  based  on  his  expert 
knowledge  as  an  aviator  and  was  tailored  to  efficiently 
capture  not  only  subject  facts,  opinions,  attitudes  and 
answers  but  also  the  reasoning  behind  the  answer.  In  short, 
the  author  based  the  interview  questions  on  what  he  thought 
would  make  sense  if  he  were  in  the  subject's  position.  The 
complete  Interview  Summary  in  Appendix  A  and  raw  interview 
notes  are  found  in  Appendix  B. 

B.  INTERVIEW  METHODOLOGY  RATIONAL 

The  primary  interview  consideration  in  regard  to  the 
subject  pool  was  an  attempt  to  get  a  somewhat  representative 
picture  from  all  fleet  squadrons.  There  are  currently  seven 
squadrons  flying  the  MH-60S.  Three  squadrons  are  located  in 
San  Diego,  CA,  three  in  Norfolk,  VA,  and  one  in  Guam. 
Mission  sets  for  each  squadron  vary  depending  on  the 
deployment  and  are  not  equally  distributed  throughout  the 
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squadrons.  Thus  a  pilot  of  one  squadron  may  encounter 
significant  different  operating  conditions  of  another  pilot 
in  another  squadron.  The  pilot  population  of  each  squadron 
is  roughly  40.  In  total,  there  are  roughly  280  active  MH- 
60S  pilots  in  the  fleet  at  any  one  time,  all  with  different 
skill  sets  and  mission  experiences.  It  should  be  noted  that 
all  pilots  initially  train  to  the  same  skill  sets  in  the 
FRS .  Squadrons,  based  on  their  operating  requirements,  may 
perform  these  mission  sets  more  or  less  frequently.  For 
example,  HSC-25  in  Guam  is  the  primary  SAR  asset  for  the 
Northern  Marinas  Islands.  Thus,  it  prosecutes  significantly 
more  search  and  rescues  than  her  sister  squadrons  in  the 
continental  United  States,  where  the  Coast  Guard  has  primary 
SAR  responsibilities . 

With  this  diversity  in  squadrons  in  mind,  HSC-3,  the 
West  Coast  MH-60S  Fleet  Replacement  Squadron  (FRS)  was 
chosen.  Instructors  are  comprised  of  a  mix  of  aviators  from 
all  the  HSC  fleet  squadrons,  thus  ensuring  a  singular  point 
of  view  of  a  particular  squadron  experience  or  geographic 


area  would 

not 

be 

represented  exclusively . 

The 

FRS 

instructor 

pilot 

pool  offered  the 

unique  advantage 

of 

collecting 

the 

most 

skilled  pilots 

throughout 

the 

HSC 

community  and  depositing  them  in  one  centralized  location. 
Mission  diversification  among  interview  subjects  is 
summarized  in  Table  3. 
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Mission 

Number  of  Pilots 

SAR 

7 

NSW/TACTICS 

5 

FAM 

7 

MEDEVAC 

2 

AH 

5 

Table  3.  Mission  experience  among  interview  subjects. 

Subjects  are  often  familiar  with  more  than  one  mission 

area . 

The  audience,  in  this  case  experienced  fleet  aviators, 
was  well  known  to  and  as  well  understood  by  the  author  (who 
was  also  the  interviewer) .  As  indicated,  the  author  is  also 
an  experienced  fleet  aviator,  and  has  flown  the  same 
model/type/series  as  the  interview  subjects.  Of  the  several 
types  of  interview  methods  presented  in  [15],  an  informal 
in-person  interview  was  chosen  based  on  the  advantages 
outline  in  Table  2.  Per  [15,  p.  14],  the  author  felt  that 
open-ended  questions,  in  which  the  key  component  of  the 
question  would  be  the  insight  that  led  the  respondent  to 
that  conclusion,  were  of  the  most  value  for  the  purposes  of 
this  study. 

Each  interview  was  conducted  with  a  written  script  in 
which  notes  were  taken  by  the  interviewer  (Appendix  A) .  The 
subjects  were  familiar  with  their  particular  cockpit 
environment,  but  were  unfamiliar  with  certain  Human  Cockpit 
Interface  (HCI)  terminology  and  concepts.  The  author  felt 
that  if  the  subjects  had  a  better  understanding  of  different 
interface  options,  a  more  frank  and  revealing  discussion 
would  be  the  result. 
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Finally,  following  guidelines  established  in  Table  4,  a 
quiet,  private  interview  room  was  used.  In  this  case  it  was 
a  briefing  space  which  the  pilots  were  both  familiar  with 
and  provided  convenient  access  as  it  was  located  in  the 
squadron  spaces.  Based  on  the  experience  of  the 
interviewer,  pilots  are  relaxed  and  more  open  to  discussion 
in  a  familiar  environment. 


Characteristics 

Done  with  a  written  script 

Advantages 

Can  explore  answers  with  respondents 

Can  assist  respondents  with  unfamiliar 

words  and  concepts 

Special  Needs 

Requires  a  quiet  area  to  conduct  the 

interviews 

Table  4.  In-person  informal  interview  attributes  (After: 

[15]). 
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IV.  INTERVIEW  RESULTS  AND  DISCUSSION 


A.  INTERVIEW  RESULTS  SUMMARY 

The  interview  method  described  in  Chapter  III  does  not 
necessarily  lend  itself  to  easily  quantifiable  summary  data 
as  the  bulk  of  the  information  is  pilot  comments  about 
particular  systems  or  cockpit  tasks.  These  comments  did 

tend  to  group  in  to  several  general  areas  of  interest. 

Topics  were: 

•  All  nine  subjects  expressed  the  need  for  a  MFD 
integrated  moving  map  to  aide  in  performing  critical 
navigation  tasks  and  for  maintaining  adequate 
situational  awareness  across  the  entire  spectrum  of 
missions.  Eight  of  nine  interviewees  had  some 

experience  with  the  Digital  Map  Kneeboard  (discussed 
in  Chapter  V)  which  was  developed  independently  from 
the  cockpit  instrument  suite.  Interviewees  stated 

that  the  kneeboard  device  was  a  poor  substitute  for 
a  fully  integrated  moving  map.  Pilots  believed  that 
use  of  the  knee  board  version  was  cumbersome  and 

presented  a  significant  disruption  to  their  normal 
scan  pattern.  They  all  stated  that  integrating  the 
functionality  of  the  DMK  in  to  the  Multi-Function 
Display  (MFD)  would  be  the  optimal  solution  based  on 
their  aviation  experiences  with  cockpit  scan 
patterns  and  the  elimination  of  the  distractions 
caused  by  "head-down"  cockpit  tasks.  The  negative 
effects  of  this  type  of  cockpit  activity  will  be 
discussed  in  Chapter  V. 


27 


•  Five  of  nine  subjects  expressed  dissatisfaction  with 
the  current  implementation  of  the  Forward  Looking 
Infrared  (FLIR) . 

•  Four  of  nine  subjects  felt  the  current  Programmable 
Key  Interface  (PKI) /Fixed  Function  Key  (FFK)  user 
interface  was  difficult  to  use. 

•  Four  of  nine  subjects  felt  there  were  readability 
issues  with  various  aspects  of  the  digital  flight 
and  malfunction  indication  displays. 

A  more  in-depth  summary  is  outlined  in  Appendix  A,  and 
raw  interview  data  is  found  in  Appendix  B. 

B.  GENERAL  INTERVIEW  DISCUSSION 

The  interview  process  was  revealing  to  say  the  least. 
Topics  ranged  from  display  symbology  color  to  menu  depth.  A 
more  detailed  summary  of  these  topics  are  presented  in 
Appendix  A.  With  every  subject,  however,  the  interview 
quickly  turned  to  the  issue  of  geo-referencing  the  aircraft 
during  missions.  Of  the  eight  subjects  familiar  with  the 
DMK,  all  eight  stated  that  the  usability  of  a  moving  map 
would  be  greatly  enhanced  if  it  was  implemented  on  the  MFD 
instead  of  the  DMK.  Two  subjects  recommended  replacing  the 
center  back-up  instruments  and  replacing  it  with  a  fifth  MFD 
used  solely  for  geo-positioning  while  another  requested 
robust  viewing  options  including  ego  and  exocentric  views . 

In  the  course  of  the  interview  process,  it  became  very 
clear  to  the  author  that  this  thesis  would  not  be  a  simple 
or  straightforward  usability  analysis  on  an  existing  cockpit 
function  or  task. 
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The  focus  of  this  thesis  quickly  turned  to  an 
exploration  as  to  why  user  expectations  were  not  met  in  the 
MH-  60  aircraft  regarding  the  incorporation  of  a  mission 
critical  information  display  (specifically,  the  need  for  a 
MFD  moving  map)  .  The  author  then  set  out  to  answer  the 
question  of  how  the  U.S.  Navy  pilots  could  be  so  grossly 
under-serviced  and  how  this  problem  could  be  rectified  in 
future  acquisitions  projects.  To  that  end,  the  remainder  of 
this  thesis  will  focus  on  the  issues  surrounding  the  design 
methodology  used  during  the  MH-60  development,  and  dedicate 
efforts  toward  ascertaining  what  went  wrong  and  how  aircraft 
system  design  and  acquisition  methods  could  be  improved.  We 
will  first  begin  with  the  discussion  of  the  importance  of 
moving  maps . 

C.  SPECIFIC  DISCUSSION  ON  MOVING  MAPS 

One  item  of  particular  interest  was  a  theme  for  which 
all  nine  subjects  expressed  as  a  concern:  the  need  for  a 
usable  moving  map.  Seven  subjects  directly  commented  that 
the  current  implementation  of  this  functionality,  the 
Digital  Map  Kneeboard  (DMK)  was  not  a  practical  solution  due 
to  usability  issues  and  was  thus  not  used.  One  of  those 
that  did  not  comment  on  the  usability  of  the  DMK  had  never 
used  the  device  and  the  other  thought  it  was  a  useful 
situational  awareness  tool  for  non-pilot  aircrew  in  the 
back.  The  drawbacks  of  the  kneeboard  DMK  solution  will  be 
explored  in  Chapter  V. 

Regardless  of  the  mission,  all  nine  subjects  stated 
that  some  form  of  a  map,  or  a  way  for  the  pilot  to  maintain 
geographic  situational  awareness,  was  a  must  to  keep  the 
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pilots  from  cognitive  overload  given  the 
missions  they  were  flying.  This  will  be 
below . 


complexity  of  the 
further  discussed 
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V. 


MOVING  MAPS  AND  THE  COMMON  COCKPIT  DESIGN 
METHODOLOGY 

A.  MOVING  MAP  RATIONAL 

Before  discussing  a  moving  map  specific  to  the  Common 
Cockpit,  a  discussion  on  the  generalities  of  moving  maps  is 
warranted . 

1 .  Moving  Maps 

In  general,  moving  maps  all  provide  the  same 
information:  a  representation  of  the  relationship  between 
the  location  of  the  user  and  a  specific  geographic  area  in 
which  the  user  is  located.  As  the  user's  position  changes, 
the  map  adjusts  to  keep  the  user's  geospatial  position  and 
thus  geospatial  awareness  accurate. 

The  benefits  of  moving  maps  as  an  enhancement  to 
situational  awareness  in  general  are  well  understood  by  both 
government  and  private  agencies  and  will  not  be  discussed  in 
this  paper.  This  paper  will  specifically  discuss  moving 
maps  in  relation  to  general  U.S.  military  flight  profiles. 

The  U.S.  military  recognized  the  need  for  a  moving  map 
as  far  back  as  1979.  The  first  digital  map  was  created  by 
Harris  Corporation  for  the  U.S.  Air  Force  F-117  Nighthawk. 
Since  then,  moving  maps  have  been  installed  by  several 
different  companies  on  aircraft,  such  as  the  C-130,  F-16, 
F/A-18,  AH-1Z ,  UH-1Y  and  the  AH-64,  to  name  a  few  [37] . 

MH-60S  and  MH-60R  mission  sets  were  briefly  outlines  in 
Chapter  II.  In  review,  the  missions  vary  for  purely  over 
water  actions  including  Anti-Submarine  Warfare  (ASW)  to 
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overland  missions  such  as  Combat  Search  and  Rescue  (CSAR  or 
AH).  From  the  author's  experience,  seldom  do  these  missions 
cover  exclusively  one  type  of  geography  over  another,  but 
instead  start  in  one  geographic  region  and  end  in  another. 
This  can  be  attributed  to  the  fact  that  Navy  helicopters  are 
often  ship-based  but  work  in  the  littorals.  Even  in  the 
case  of  open  water  operations,  artificial  boundaries  are 
instantiated  by  naval  battle  groups  to  de-conflict 
dissimilar  operations.  An  example  of  this  would  be  ensuring 
low-flying  aircraft  such  as  helicopters  do  not  inadvertently 
wander  in  the  carrier  landing  pattern  of  much  faster  fixed- 
wing  aircraft.  Even  purely  ASW  work  requires  to  some  extent 
knowledge  of  sea  bottom  topography.  Lockheed  Martin  came  to 
this  same  conclusion  while  analyzing  the  MH-60R  requirements 
for  the  ASW  mission  and  initiated  an  Independent  Research 
and  Development  (IRAD)  project  to  explore  possible 
implementations  [38] . 

Generally,  from  the  author's  experience,  a  sizable 
portion  of  Navy  flying  is  either  overland  or  in  close 
proximity  to  some  form  of  land  mass  or  relevant  geographical 
partitioning.  This  may  include  international  maritime 

boarders  as  well  as  designated  "restricted"  areas  where 
entry  would  violate  national  or  international  flight 
regulations.  Thus,  one  should  conclude  that  geographical 
situational  awareness  is  applicable  to  both  overland  and 
oversea  mission  sets  and  is  thus  entirely  applicable  to  the 
MH-60S  and  MH-60R  and  their  associated  missions. 

2.  Moving  Map  MH-60S  Implementation 

With  the  corporate  understanding  of  the  benefits  of 

moving  maps  prevalent  in  the  helicopter  community  and 

32 


aviation  in  general,  the  question  is  begged  on  how  did  a 
moving  map  get  overlooked  in  the  original  common  cockpit 
design  process? 

Prior  to  [30],  the  U.S.  Navy  never  specifically 
identified  a  moving  map  solution  to  navigation  and  other 
functional  requirements  defined  in  the  ORD.  This  has  the 
potential  to  make  a  coherent  human-cockpit  interface  design 
difficult  and  recommendations  on  this  approach  will  be 
discussed  later.  Sprinkled  throughout  the  ORD  were  numerous 
requirements  to  display  some  type  of  geo-spatial  information 
to  the  crew.  For  example,  section  4. 2. 1.1,  in  discussing 
the  Airborne  Mine  Counter  Measures  (AMCM)  functional 
requirements  states  the  following: 

A  precise  helicopter  AMCM  minefield  navigation 
system  is  required  to  accurately  determine, 
display,  record  and  report  geo-spatial  position 
of  mine-like  object...  cockpit  displays  shall 
provide  the  capability  for  the  aircrew  to 
maneuver  the  helicopter  along  a  desired/selected 
track.  [30] 

Consideration  was  given  to  an  integrated  moving  map  for 
the  Common  Cockpit  prior  to  [30] .  Tasked  by  the  Navy,  Naval 
Research  Laboratory  did  discuss  the  need  for  an  integrated 
moving  map  for  the  MH-60S  in  2001.  Although  the  initial 
plan  was  to  implement  the  first  MH-60S  moving  map  to  support 
the  CSAR  mission,  the  major  thrust  of  the  program  was  to 
help  support  the  ASW  and  MCM  mission  [39] .  The  push  for  the 
moving  map  was  also  driven  by  the  success  that  moving  maps 
had  in  providing  heightened  situational  awareness  in  the 
F/A-18  Hornet  and  AV-8B  Harrier  [40] . 

Prior  to  production  aircraft  120,  the  possibility  of 

MFD  integrated  moving  map  was  moot.  The  first  generation  of 
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the  Common  Cockpit  included  as  part  of  its  hardware  a  key 
computing  device  called  the  Flight  Mission  Computer  (FMC) 
that  lacked  sufficient  computing  power  to  implement  a  moving 
map  [41]  .  Per  [5]  ,  the  FMCs  "are  provided  for  information 
processing  and  data  management.  The  FMCs  execute  Flight 
Management  Program  (FMP)  software  and  provide  all  flight 
management  functions"  [5,  p.  VII-15-20] .  Since  production 
aircraft  120,  however,  the  all  FMCs  in  new  production 
aircraft,  as  well  as  fleet  aircraft,  have  been  replaced 
with  the  Mission  Computer  (MC) ,  which  is  capable  of  driving 
the  necessary  hardware  and  software  to  utilize  the  hardware 
map  features  already  located  on  the  MFDs  [41], [42] . 

Even  with  the  temporary  technical  limitation  posed  by 
the  FMC,  the  reason  that  a  moving  map  was  not  an  initial 
requirement  in  the  Common  Cockpit  is  still  not  completely 
clear.  As  discussed  above,  the  benefits  of  a  moving  map  are 
well  known  and  would  have  been  one  of  the  fundamental  issues 
discussed  by  any  design  team  based  on  ORD  functional 
requirements.  Thus,  the  cockpit  design  methodology  should 
at  the  least  have  driven  the  inclusion  of  the  moving  map 
requirement  once  technical  limitations  were  overcome.  Why 
didn't  it?  One  possible  reason  could  be  the  cockpit  design 
process  used  by  Lockheed  Martin. 

3 .  Lockheed  Martin  Cockpit  Design  Methodology 

According  to  [43] ,  Lockheed  Martin  loosely  followed  in- 
house  systems  engineering  design  methodology  titled  "Process 
Guidance  Series— System  Engineering:  Human-Computer  Interface 
Requirements  (HCIRS)."  This  methodology  was  more  or  less 
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standard  throughout  the  industry  and  eventually  became 
formalized  as  the  Department  of  Defense  Architecture 
Framework  (DoDAF) ,  Version  1.0. 

It  should  be  noted  that  without  a  singular  first-hand 
view  of  the  entire  Common  Cockpit  design  process  or  clear 
documentation  at  every  step,  it  is  impossible  to  accurately 
map  each  individual  design  stage  to  the  components  of  the 
Lockheed  Martin  methodology.  Methodology  is  further 
obscured  by  the  fact  that  exact  composition  of  each  group 
(Human  Factors  Engineering,  Software  Engineering,  etc.),  as 
delineated  in  [6],  cannot  be  accurately  determined  within 
the  scope  of  this  thesis.  That  said,  documentation  provided 
by  Lockheed  Martin  to  the  autho,r  as  well  as  [43],  indicates 
that  this  methodology  was  generally  followed.  It  should 
also  be  noted  that  according  to  [44]  the  specifics  of  human 
factors  are  "greatly  influenced  by  customer  requirements  and 
expectations . " 


a.  Lockheed  Martin  Process  Guidance  Series 
Systems  Engineering:  Human-Computer 

Interface  Requirements  (HCIRS)  Overview 

Lockheed  Martin' s  design  methodology  is  a  systems 
engineering  approach  to  all  encompassing  approach  to  Human 
Computer  Interface  (HCI) .  It  uses  a  straightforward 

iterative  design  process  for  development,  design  and  test 
implementations  of  HCI  requirements. 

jb.  Systems  Engineering  Process 

Reference  [6]  is  a  framework  to  help  system 
engineers  develop  a  usable  HCI  for  users  of  any  type  of 
computer  system  and  is  not  specific  to  aviation 
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applications.  It  provides  "recommended  contents  for  those 
sections  of  a  system,  subsystem,  configuration  item,  or 
interface  requirements  specification  used  in  documenting  HCI 
requirements  [6,  p.  7]  .  These  recommended  contents  are 
outlined  in  Figure  8. 
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Figure  8 .  Lockheed  Martin  Human  Computer  Interface 

Requirements  (HCIRS)  contents  (From:  [6])  . 

Per  [6],  the  contents  are  meant  to  describe  the 
interface  between  the  user  and  the  system.  The  "how"  of 
software  and  hardware  design  is  documented  in  separate 
specifications  [6] . 

c.  The  Iterative  Process 

Reference  [6]  has  divided  the  design  process  in  to 
eight  distinct  steps  (Figure  9) . 
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Step  1. Generate  an  Operational  Concept 

Step  2. Define  the  Users 

Step  3. Elaborate  Functions  and  Tasks 

Step  4. Analyze  Human  Tasks  and  Interfaces 

Step  5. Specify  Computer  Interface  Requirements 

Step  6. Define  a  Human-Computer  Interface  Configuration 

Step  7. Specify  Documentation 

Step  3. Specify  Qualification  Requirements 

Figure  9.  Lockheed  Martin  eight  step  HCI  design  process 

(From:  [ 6] ) . 

As  stated  earlier,  this  process  is  both  sequential 
and  iterative.  Design  teams  will  make  decisions,  review 
them  with  users  and  modify  these  designs  an  indeterminate 
number  of  times  until  a  consensus  is  reached  as  to  meeting 
the  functionality  of  that  particular  system.  "User 

evaluations  of  the  prototype  are  conducted  at  various 
iterations  to  obtain  users'  feedback  early  and  incorporate 
it  into  the  design,  as  appropriate"  [6].  Iteration  occurs 
between  steps  three  and  eight  of  the  design  process. 

Step  three  is  the  step  in  which  "functional 
allocation"  occurs.  Here,  "functions  are  allocated  to 
humans  or  to  machines"  [6,  p.  27],  Allocation  decisions  are 
based  on  several  criteria  including  human  and  machine 
limitations  and  data  from  functional  analysis,  as  well  as 
past  engineering  experience  and  cost-effectiveness  of 
design.  To  some  extent,  the  remainder  of  the  iterate 
process  refine  this  mapping  of  functions  to  functionality 
and  get  it  to  work  in  the  context  of  usability.  This  in 
turn  makes  step  three  the  most  crucial  to  the  entire 
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iterative  process.  Any  missteps  here  may  prove 
irrecoverable  for  the  remainder  of  the  process  until 
iteration  returns  to  the  starting  point.  This  logic  can 
also  be  applied  to  the  non-iterative  part  of  this  process 
starting  at  step  one  (Generate  Operational  Concept) .  If  the 
concept  is  mal-formed,  the  entire  process  will  thus  be 
malformed  since  there  is  no  way  to  recover  without  a 
complete  re-initialization  of  the  entire  design  process. 

In  summary,  the  reader  should  keep  in  mind  that 
the  ultimate  goal  of  this  design  process  is  to  map  required 
system  functionality  (step  3  of  Figure  9)  to  a  specific 
functionality  within  the  final  design  (step  8  of  Figure  9) . 
Once  this  criterion  is  met,  it  is  possible  to  declare  the 
system  goals  complete.  This  means  that  unless  a  very 
specific  moving  map  requirement  was  specified  (which  was  not 
the  case  in  the  original  MH-60S  ORD) ,  the  final  design  could 
vary  widely  and  would  most  likely  be  the  best  solution  from 
an  engineering  standpoint,  not  necessarily  a  usability 
standpoint . 

4 .  Digital  Map  Kneeboard  (DMK) 

The  introduction  of  Block  II  and  III  production  models 
and  the  implementation  of  the  Armed  Helo  mission  brought 
the  need  for  a  moving  map  to  the  forefront.  Hamstrung  by 
the  FMC  limitation  as  discussed  in  Chapter  V,  NAVAIR  opted 
to  integrate  a  kneeboard  moving  map  and  introduced  a  change 
to  the  MH-60S  ORD  that  specifically  outlined  a  kneeboard 
moving  map  specification  [30].  Section  4.3.9  of  [30] 
defines  the  requirement: 
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A  kneeboard  moving  map  which  is  useable  during 
both  unaided  and  Night  Vision  Device  (NVD)  flight 
will  provide  digital  navigation  for  each  pilot. 

The  aircraft  will  be  modified  to  provide  primary 
navigation  (either  INS  or  GPS)  position 
information  and  power  supply  to  support  the 

moving  map.  The  MH-60S  kneeboard  moving  map 
shall  be  capable  of  pre-flight  loading  and  in¬ 
flight  display  of  National  Geospatial- 
Intelligence  Agency  (NGA)  raster  product  format 
data  and  vector  data  that  incorporates  and 
overlays  geo-referenced  navigation  and  waypoint/ 
flight  data  onto  a  common  map  background.  The 

moving  map  shall  be  capable  of  input  and  output 

in  either  latitude/longitude  or  Military  Grid 
Reference  System  (MGRS) .  When  the  Navy 

implements  the  Common  Grid  Reference  System 
(CGRS)  ,  it  will  be  incorporated  into  the  moving 
map  system.  A  cockpit  moving  map  display  greatly 
increases  pilot  situational  awareness.  A  self- 
contained  moving  map  system  will  be  an  objective 
system  for  the  MH-60S. 

If  a  need  for  moving  map  was  realized  in  the  ORD,  why 
was  the  kneeboard  solution  incorporated  and  not  the  "self- 
contained  moving  map  solution"  described  above  as  the  final 
solution?  Before  this  question  can  be  answered,  a  brief 
discussion  of  the  DMK  will  be  undertaken  to  orient  the 
reader  with  the  kneeboard  solution. 

a.  Digital  Map  System 

The  answer  to  the  Change  2  ORD  requirement  was  the 
Digital  Map  System  (DMS) .  Developed  by  Vertical-flight 
Systems,  Test  Analysis  and  Research  (VSTAR) ,  a  government 
owned  facility,  the  DMS  consists  of  three  distinct 
components  (Figure  8  and  Figure  9)  :  a  Digital  Map  Junction 
Unit  (DMJU) ,  a  Digital  Map  Loading  System  (DMLS)  and  three 
Digital  Map  Keyboards  (DMK)  [7] . 
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Figure  10.  DMS  (From:  [7]). 


Figure  11.  Current  fleet  DMK.  Pen  included  for  size 

reference  only. 


The  current  kneeboard  moving  map  implementation 

was  an  offshoot  of  an  older  Fujitsu  touchpad  laptop  that  had 

been  tested  previously.  Based  on  this  concept  the  current 

kneeboard  was  designed  and  prototyped  by  NAVAIR  during  2004. 

Production  of  operational  models  was  handled  by  the  Army 
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(AMRDEC)  Aviation  and  Missile  Research,  Development  and 
Engineering  Center— Prototype  Integration  Facility  (PIF)  in 
Huntsville  (Redstone  Arsenal) ,  Alabama  [45] . 

Designed  to  be  worn  on  the  pilot's  thigh  while 
seated  in  the  aircraft,  the  kneeboard  is  approximately  the 
size  a  medium-sized  book  or  standard  military  kneeboard  in 
length,  width  and  thickness  (Figure  11  and  Figure  12)  and 
weighs  around  four  pounds  [8] .  User  Human  Machine  Interface 
(HMI)  controls  consist  of  an  8.5-inch  (diagonal)  resistive 
touch  screen,  on/off  switch,  touch  screen  disable  switch, 
backlight  control  and  right  mouse  click  switch.  Software 
consists  of  Microsoft  Windows  XP©  running  the  AN/AYQ  -26 
Topographic  Support  Set  (Figure  13) .  This  set  integrates 
aircraft  navigation  data  with  respect  to  digital  maps  [7], 
Forward  Looking  InfraRed  (FLIR)  composite  video  input,  two 
10/100  Ethernet  ports  and  a  MIL-STD-1553B  Data  Collection 
PCB  [8]  . 


Figure  12.  Current  fleet  DMK.  Pen  included  for  size 

reference  only. 
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Windows  XP  Operating  System 
V§Xmg£  Viewer  S/W  (Video  Window) 
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-  Weight:  <  4  lbs 

-  Size:  Navy  kneeboari 
Display 
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*  Oil  Off 

*  Brightness  Ctrl 


Figure  13.  DMK  Specifications  (After:  [8]) . 


Of  particular  interest  is  the  integration  of  the 
mission  planning  software  FalconView©  to  the  DMK. 
FalconView©  is  a  common  tool  used  by  aircrew  across  all  the 
services  for  mission  planning. 

jb.  Pilots  Likes /Dislikes  and  Limitations  of 
Heads -down  Devices 


The  in  the  scope  of  the  interview  conducted  for 
this  thesis,  the  DMK  was  universally  discounted  by  all 
pilots  interviewed  as  a  useful  front  seat  tool  for  any  type 
of  relevant  geospatial  situational  awareness  information. 
Based  on  comments  documented  in  Appendix  B,  this  is 
primarily  due  to  the  heads-down  nature  of  the  DMK. 
Interview  subjects  reiterated  that  the  DMK  was  much  more  a 
distraction  than  help  to  mission  accomplishment. 

This  finding  is  not  surprising.  The  negative 
impact  of  any  heads-down  activity  in  a  cockpit  is  well 
documented  and  blamed  for  a  number  of  aircraft  mishaps  [46] 
analyzed  National  Transportation  and  Safety  Board  accounts 
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of  accidents  attributed  to  crew  error.  Of  those  reported, 
"nearly  half  of  these  accidents  involved  lapses  of  attention 
associated  with  interruptions,  distractions,  or 
preoccupation  with  one  task  to  the  exclusion  of  another 
task."  Of  these  distracting  activities,  four  categories 
were  defined: 

•  both  internal  and  external  communication 

•  searching  for  VMC  traffic 

•  responding  to  abnormal  situations 

•  head-down  work 

Reference  [46]  also  analyzed  107  of  NASA's 
Aviation  Safety  Reporting  System  (ASRS)  reports  that 
involved  competing  tasks.  Sixty-nine  percent  of  these 
reports  were  attributed  to  "either  failure  to  monitor  the 
current  status  or  position  of  the  aircraft,  or  failure  to 
monitor  the  actions  of  the  pilot  who  was  flying  or  taxing" 
[46]  .  In  35  of  the  ASRS  reports,  the  pilot  not  flying  was 
distracted  from  monitoring  the  flying  pilot  from  other 
tasks,  of  which  13  involved  some  kinds  of  head-down 
activity . 

Airbus  also  conducted  a  review  of  safety  reports 
and  found  similar  data  [16]  .  Based  on  the  U.S.  Aviation 
Safety  Action  Program  (ASAP) ,  Airbus  stated  that 
"interruptions  and  distractions  are  the  main  threat  facing 
flight  crews."  Airbus  defines  a  threat  as  "a  condition  that 
affects  or  complicates  the  performance  of  a  task  or  the 
compliance  with  applicable  standards."  In  reviews  of  the 
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ASRS  ,  Airbus  calculated  that  head-down  activity  accounted 
for  16-22  percent  of  the  factors  involved  in  interruptions 
and  distractions ,  as  listed  in  Table  5  [16]  . 


Factor 

%  of  Events 

Omission  of  action  or  inappropriate  action 

72  % 

Inadequate  cnew  coord i nation,  cross-check  and  back-up 

63  % 

Insufficient  or  loss  of  lateral  or  vertical  situational  awareness 

52  % 

Inadequate  or  insufficient  understanding  of  prevailing  conditions 

48  % 

Slow  or  delayed  action 

45  % 

Incorrect  or  incomplete  pilot  /  controller  communications 

33  % 

{ Sources  :  Flight  Safety  Foundation  -  ALAR  -  199£P1I999  ) 

Table  5.  Interruption  and  distraction  factors  (From:  [16]). 

The  effect  of  these  interruptions  and 

distractions ,  in  which  head-down  activity  comprises  almost  a 
quarter,  is  to  "break  the  flow  of  ongoing  cockpit 
activities,"  including  [16]: 

•  Standard  Operating  Procedures  (SOPs) 

•  Normal  Checklists 

•  Communications 

•  Monitoring  tasks 

•  Problem  solving  activities 

The  effects  of  head-down  activity  and  the 

resultant  laundry  list  of  consequences  above  are  no  surprise 
to  seasoned  fleet  aviators.  Limiting  head-down  activity  to 
a  minimum  is  a  golden  rule  taught  in  flight  school  and 
constantly  reiterated  during  countless  safety  briefs  and 
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squadron  level  training.  The  head-down  environment  is  so 
distracting  that  announcing  that  the  non-flying  pilot  is 
"heads-down"  is  very  common  practice  and  highlights  the  need 
for  extra  vigilance  by  the  flying  pilot  as  well  as  other 
flight  crewmembers.  Physiological  affects  aside,  head-down 
is  not  an  activity  that  should  be  performed  often  in  the 
cockpit . 

This  knowledge  of  the  inherent  dangers  of  head- 
down  can  also  be  interpreted  from  the  U.S.  Navy's  own 
research  into  glass  cockpits.  In  researching  moving-map 
systems  for  multi-functional  helicopter  missions,  the  Naval 
Research  Laboratory  did  not  even  consider  a  kneeboard 
application  and  instead  focused  its  research  on  an  in-dash 
MFD  integrated  solution  [47], [40] . 

Finally,  [48]  describes  one  of  the  potential 
hazards  of  advanced  interfaces  interfering  with  aircrew 
situational  awareness.  It  warns  that  "too  much  programming 
and  head  down  times  [that]  takes  place  at  low  altitude,  and 
during  time  of  intense  tactical  activity, "  is  a  concern  when 
developing  a  new  interface  system  (p.  8) . 

c.  Planned  Obsolesce  of  the  DMK 

Although  sold  as  a  solution  to  the  moving  map 
issue,  NAVAIR  did  recognize  that  it  was  not  the  ideal 
solution.  Per  [7]  and  [30]  this  implementation  of  moving 
map  functionality  was  inferior  to  a  MFD  integrated  solution: 
"but  the  ultimate  solution  would  be  to  integrate  the  moving 
map  system  into  the  normal  OSI  on  the  mission  display  [7], 

p.  10]  ." 
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Other  than  the  fact  of  denying  the  users  of  the 
MH-60S  access  to  a  known  superior  navigation  system  in  the 
hear  and  now,  planning  for  a  major  systems  change  after  the 
aircraft  has  started  full-rate  production  is  an  expensive 
proposition  and  a  well-known  acquisitions  "no-no"  and 
harkens  to  the  now-defunct  serial-approach  acquisitions 
process.  Per  [9]  the  most  costly  place  to  implement  product 
changes  are  after  operational  testing  or  full-rate 
production  as  shown  in  Figure  14. 


HIGH 


m 

ec. 

h 

d 

Q 


LOW 


TIME 


Figure  14.  Cost  of  design  changes  as  a  function  of  time 

(From:  [ 9] ) . 


B.  DESIGN  METHODOLOGY  FLAWS  AND  A  SUGGESTED  ALTERNATE 
DESIGN  METHODOLOGY 

Clearly,  the  DMK  is  a  poor  solution  to  the  moving  map 
issue.  This  statement  can  be  made  not  only  based  on 
research  presented  above  but  also  validated  by  nine  of  nine 
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pilots  interviewed  requesting  the  integration  of  a  moving 
map  despite  the  fact  that  one  already  exists  in  the  DMK. 
The  question  is  still  begged:  how  did  the  DMK  become  the 
solution?  Per  [49] ,  the  issue  was  timing.  NAVAIR  realized 
that  the  block  II  Armed  Helo  navigation  requirements  could 
be  solved  by  a  moving  map  but  was  still  limited  by  the  FMC 
as  previously  discussed.  The  MC  was  planned  as  an  upgrade 
but  would  not  be  ready  in  time  for  block  II  incorporation. 
The  solution  was  the  DMK.  But  given  all  the  issues  with  a 
head-down  display,  why  was  this  solution  not  rejected  as 
inadequate  as  interview  results  so  clearly  indicated?  The 
answer  could  lay  in  the  standard  HCI  design  methodology 
utilized  by  Lockheed  Martin. 

The  primary  issue  in  the  design  process  could  be  the 
incorporation  of  previous  designs  in  the  generation  of  HCI 
requirements  as  described  by  [6].  This  step  calls  for  the 
"study  of  earlier  similar  systems  to  identify  firmly 
established  interface  practices  and  standards  [6,  p.  9]. 
The  potential  pitfall  here  is  the  earlier  system  being 
reviewed.  If  that  design  is  flawed,  and  that  flaw  was  not 
recognized  by  the  design  team,  the  fundamental  flaw  has  the 
potential  to  be  carried  over  to  the  new  design.  Give  the 
discussion  of  head-down  issues  from  above,  the  conclusion 
that  this  is  precisely  what  happened  in  the  DMK  can  be 
reasonably  drawn. 

Although  in  itself  the  inclusion  of  a  prior  design  is 
not  a  bad  idea,  somehow  a  useless  moving  map  solution  was 
still  produced  by  the  design  methodology.  What  can  be  done 
to  help  eliminate  this  chink  in  the  design  armor?  A  better 
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and  ultimately  more  efficient  approach  to  cockpit  design  may 
be  a  design  philosophy  commonly  known  as  Crew-Centered 
Design  (CCD) . 

1 .  Crew  Centered  Design  Philosophy 

The  Crew  Centered  Design  (CCD)  concept  is  similar  to 
the  Lockheed  Martin/DoDAF  methodology  in  that  it  professes 
the  same  iterative  approach  to  design  in  which 
implementations  are  prototyped  and  tested.  It  differs  from 
the  industry  standard  HCI  systems  engineering  approach  in 
that  it  is  less  of  a  rigid  methodology  and  more  of  a 
philosophy  and  emphasizes  a  more  holistic  view  of  cockpit 
systems  integration  with  flight  crew  usability  as  a  key 
component  of  that  system.  CCD  places  a  much  greater 
importance  on  input  from  experienced  aircrew  personnel  "at 
the  beginning  of,  and  throughout,  the  cockpit  design 
process"  [ 50 ] . 

Although  each  instantiation  of  the  industry  standard 
iterative  systems  engineering  process  centered  HCI  design 
methodology  may  be  different  from  organization  to 
organization,  generally,  they  all  follow  the  model  detailed 
in  Figure  15.  This  representation  almost  maps  step  for  step 
to  the  Lockheed  Martin  process  described  in  an  earlier 
section  of  this  thesis. 
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Figure  15.  Systems  engineering  iterative  HCI  design 

process  (From  [10]). 

While  utilizing  the  general  structure  from  Figure  14, 
the  Crew  Centered  Design  philosophy  takes  a  completely 
different  view  of  what  is  important  in  cockpit  design.  It 
de-emphasizes  the  performance  of  individual  components  and 
the  sterile  implementation  of  functionality  and  instead 
views  success  as  how  well  the  crew  and  cockpit  perform 
together  in  the  accomplishment  of  a  given  task.  To  this 
end,  CCD  places  a  much  larger  emphasis  on  the  inclusion  of 
the  flight  crew  in  every  step  of  the  design  process  [10]  . 
Fundamental  components  of  CCD  include: 

•  Acknowledgement  that  the  flight  crew  has  the 
ultimate  responsibility  for  the  aircraft  [51] . 

•  Inclusion  of  the  user  (aircrew)  more  intimately  in 
the  design  process  [10]. 
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•  Consider  the  usability  of  the  cockpit  as  a  major 
system  such  that  it  equivalent  to  engines  and 
airframe  integration  [10]  . 

•  Total  flight  crew/flight  deck  performance  is  more 
important  that  performance  of  individual  components 
[10,  p.  7] 

•  Test  and  evaluation  should  occur  as  early  in  the 
design  process  as  possible  to  avoid  implementation 
of  poor  design  decisions  [10]  . 

The  Crew-Centered  Design  philosophy  applied  to  the 
traditional  design  methodology  is  depicted  in  Figure  16. 
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Motes:  (1 )  Philosophy  should  affect  design  process  wherever  design  decisions  are  explicitly  or  implicitly  made 
For  example,  aircraft  operational  and  functional  requirements  should  be  independent  of  design 
decisions,  but  often  they  are  not;  function  allocations,  pilot  interfaces,  and  flight  deck 
requirements  are  sometimes  involved. 

(2)  Philosophy  should  affect  the  operation  or  function  of  the  aircraft  if  pilot  roles  dictate  that  the 

aircraft  interact  with  the  outside  environment  in  certain  ways  (e.g.5  must  he  able  to  perform 
a  visual  approach  or  manual  landing  because  the  pilot  has  ultimate  authority  over  critical  flight 
functions). 


Figure  16.  Inserting  the  Crew-Centered  Design  philosophy 

in  to  the  traditional  design  methodology  (From:  [10], 

p.  9]) 
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As  its  name  implies,  one  of  the  major  elements,  if  not 
the  major  element,  is  frequent  and  focused  input  by  the 
experienced  aircrews  that  may  operate  in  that  cockpit 
environment . 

An  optimized  design  and  analysis  process  [Crew- 
Centered  Philosophy]  should  take  advantage  of 
aircrew  input.  The  aircrew,  as  a  user,  can 
provide  a  tactical  evaluation  of  the  design 
product  and  provide  valuable  insights.  [50,  p.  1] 

2 .  Recommended  Changes  to  Lockheed  Martin  HCI  Design 

Methodology  Based  on  the  CCD  Philosophy 

There  are  several  areas  on  which  the  application  of  the 
CCD  philosophy  would  enhance  the  Lockheed  Martin  design 
process.  These  include: 

a.  Use  of  Design  Methodology  Specifically 
Developed  for  Cockpit  Design 

Design  fundamentals  and  operating  environments  are 
not  the  same  across  the  HCI  spectrum.  Fundamentally  the  LM 
method  and  its  successor  DoDAF  are  a  broad  approach  to 
general  HCI  design.  Given  the  highly  dynamic  environment  of 
the  flight  deck,  a  set  of  very  specific  usability 
requirements  exist.  Reference  [52]  argues  that  "In  the 
complex,  dynamic,  tightly  regulated  environment  of  aviation, 
the  challenge  of  performing  a  usability  evaluation  expands 
considerably  in  comparison  to  evaluation  of  traditional 
human-computer  interaction  (HCI)  applications"  [52,  p.  396] . 
Unlike  other  stationary  systems  that  are  captured  by  general 
HCI  design  methodologies  aircrew  face  a  much  more  dynamic 
and  thus  fundamentally  different  design  context.  Regardless 
of  the  current  task  for  the  aircrew  "The  most  important  task 
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is  aviating—  keeping  the  flow  of  air  over  the  wings  such  as 
to  maintain  lift  [53,  p.  460]  That  is  exemplified  in  the 
flight  school  mantra  of  aviate ,  navigate ,  communicate! 
Regardless  of  secondary  tasks  these  three  tasks  must  still 
be  accomplished  with  absolute  precision  since  the  price  of 
failure  usually  catastrophic.  There  is  therefore  a  constant 
competition  in  the  flight  deck  environment  for  the  resource 
of  pilot  attention. 

The  competing  tasks  involve  maintaining  situation 
awareness  for  hazards  in  the  surrounding 
airspace,  navigating  to  3-D  points  in  the  sky, 
following  procedures  related  to  aircraft  and 
airspace  operations,  communicating  with  air 
traffic  control  and  other  personnel  on  the  flight 
deck,  and  monitoring  system  status.  [53,  p.  460] 

This  specific  task  environment  cannot  be  said  of  a 
user  of  a  desktop  terminal  or  even  an  operator  of  a 
sophisticated  nuclear  power  plant  control  station  for  which 
a  general  HCI  methodology  would  cover.  Reference  [6]  does 
attempt  to  make  this  point.  In  step  one,  it  directs  systems 
engineers  to  capture  "operational  modes;  and  any  special 
environmental  conditions  that  must  be  accommodated  by  the 
system  [6,  p.  27]  .  Depending  on  the  expediency  of  the 
project,  this  broad  brush  approach  to  capturing  the 
operating  environment  has  a  lot  of  potential  to  miss  crucial 
elements.  Plus,  understanding  that  the  fundamentals 
described  above  are  common  to  any  cockpit  design,  it  seems  a 
waste  of  resources  to  continually  re-invent  the  wheel  for 
each  functional  requirement. 
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b.  Cost  Effectiveness  Must  be  Evaluated  from  a 
Holistic  Standpoint 

Limiting  cost  as  a  design  criteria:  Per  the 
Lockheed  Martin  method  "the  most  cost-effective  design 
alternative  is  selected  [6,  p.  26,  Figure  6]  during  step  3 
of  the  iterative  design  process.  Although  cost  is  an 

important  element,  it  should  not  be  applied  as  the  bottom- 
line  selection  criteria  for  each  individual  function.  CCD's 
philosophy  of  viewing  the  system  as  more  than  the  sum  of  its 
parts  must  also  be  applied  to  the  cost  criteria.  A 
functional  requirement  that  costs  more  may  in  fact  drive 
down  the  cost  of  a  related  function.  Thus,  cost  comparison 
may  be  better  served  by  evaluating  the  effectiveness  of 
aircrew  tasks  (or  combinations  of  functions) .  For  example, 
if  "navigation"  was  evaluated  as  a  task,  several  functional 
requirements  may  be  included  in  this  grouping.  Since  CCD  is 
crew-centered  and  more  dependent  on  "operator  input  and 
experience"  [50,  p.  1],  there  is  a  greater  chance  that 
aircrew  will  recognize  that  task  accomplishment  would  be  the 
criteria  for  success  instead  of  simply  meeting  a  functional 
requirement.  In  short:  meeting  a  functional  requirement 
does  not  mean  that  the  task  is  accomplished  in  the  most 
efficient  way. 

c.  View  the  Cockpit  as  a  Sum  of  Its  Parts  for 
Design  Decisions 

Eliminate  a  function  by  function  approach  to 
design:  The  current  accepted  cockpit  design  methodology 
used  on  the  Common  Cockpit  evaluates  each  functional 
requirement  as  a  pseudo  standalone  requirement.  CCD's 
holistic  aircrew  centered  approach  would  tie  common 
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functional  requirements  together  and  address  that  the  whole 
may  in  fact  be  greater  than  the  sum  of  the  parts.  It  is 
easy  to  conclude  that  understanding  the  underlying  need  for 
geospatial  situational  awareness  an  experienced  flight  crew 
would  immediately  be  able  to  connect  the  dots  between 
different  requirements  for  mapping. 

In  the  case  of  the  Common  Cockpit,  the  need  for 
geospatial  positioning  is  scattered  throughout  each 
different  aircraft  block  requirement  in  the  MH-60S  ORD.  For 
this  discussion  the  reader  should  note  that  this  Common 
Cockpit  requirements  review  has  been  limited  to  just  the  MH- 
60S  ORD  and  does  not  factor  in  functional  requirements 
defined  in  the  MH-60R  ORD. 

Block  I  aircraft,  section  4.1.2  of  [30],  as  well 
as  section  4. 2. 4.1  of  Block  II  requirements,  requires  that 
the  "MH-60S  Communications  and  Navigation  subsystems  are 
required  that  will  enable  aircraft  to  operate  within  the 
Global  Air  Traffic  Management  (GATM)  system  [30,  p.  14]." 
The  GATM: 

Is  a  concept  for  satellite-based  communication, 
navigation,  surveillance  and  air  traffic 
management.  The  Federal  Aviation  Administration 
and  the  International  Civil  Aviation 
Organization,  a  special  agency  of  the  United 
Nations,  established  GATM  standards  in  order  to 
keep  air  travel  safe  and  effective  in 
increasingly  crowded  worldwide  air  space.  [54] 

Block  II  navigation  requirements  are  outlined  in 
section  4. 2. 1.1  of  [30].  The  AMCM  specific  requirements 
state  that  the  "cockpit  displays  shall  provide  the 
capability  for  the  aircrew  to  maneuver  the  helicopter  along 
a  desired/selected  track  (p.  19)  . "  Unlike  Block  I  and  II 
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communication  and  navigation  requirements,  oddly  Block  III 
navigation  and  situational  awareness  requirements  completely 
forgo  any  mention  of  GATM  and  instead  section  4.3.9 
describes  the  functionality  requirements  of  the  DMK 
discussed  in  detail  above  [30]  .  Communications  and 
navigation  requirements  are  also  outlined  in  the  Other 
System  Characteristics  subsection  (4.6)  in  sections  4.6.6 
and  4.6.7,  respectively.  Neither  section  mentions  GATM  but 
4.6.7  outlines  a  functionality  that  could  be  construed  as  a 
situational  awareness  tool  for  GATM  implementation: 

The  MH-60S  helicopter  shall  have  the  capability 
to  pre-load  (both  electronically  and  manually) 
geo-referenced  navigation  waypoints  and  flight 
plans,  and  provide  the  ability  to  manipulate 
these  waypoints/f light  plans  in  flight.  The 
navigation  system  shall  be  capable  of  displaying 
to  the  pilots  the  position  of  surface  contacts  in 
and  around  the  battle  group.  [30,  sect.  4.6.7,  p. 

35] 

A  possible  side  effect  of  sprinkling  functional 
requirements  throughout,  may  be  that  the  same  functional 
requirement  would  be  designed  two  different  ways  in  two 
different  projects.  In  the  case  of  GATM,  the  Common  Cockpit 
had  no  specific  resultant  usability  other  than  a  basic 
avionics  package  and  rudimentary  mapping  abilities  discussed 
below.  This  would  then  seem  to  meet  the  functional 
requirements  specified  by  the  MH-60S  ORD  sections  discussed 
above.  However,  when  Lockheed  Martin  designed  the  glass 
cockpit  for  the  improved  avionics  suite  for  the  Air  Force  C- 
5,  the  result  was  a  true  moving  map  based  on  Commercial-of f- 
the-Shelf  (COTS)  packages  found  in  the  Boeing  777  among 
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others  [55] .  Of  course  without  an  in-depth  analysis  of  the 
C-5  program,  it  is  impossible  to  make  this  correlation  with 
100  percent  accuracy. 

Finding  cockpit  functional  requirements  should  not 
be  like  hunting  for  Easter  Eggs.  By  eliminating  the  stoic 
focus  on  stove-piped  design,  CCD  ties  these  initially 
disparate  functional  requirements  together  by  recognizing 
that  they  all  accomplish  the  same  basic  task  of  geospatial 
positioning.  The  end  design  result  would  be  a  much  better 
integrated  mapping  system  that  may  potentially  greatly 
reduce  costs  and  improve  system  flexibility  in  the  long  run. 
The  need  to  unify  cockpit  requirements  in  to  one 
encompassing  ORD  is  also  a  desire  of  the  program  manager  per 
[35]  . 


d.  Carefully  Consider  Incorporating  Previous 
Designs 

References  [56]  and  [11]  indicate  that  one  of  base 
designs  for  the  CC  was  the  Light  Airborne  Multipurpose 
System  (LAMPS)  MK  III  Block  II  program.  This  is  due  to  the 
fact  that  the  MH-60R  is  a  replacement  for  the  current  LAMPS 
SH-60B  as  stated  earlier  [4]  .  The  LAMPS  MK  III  system  was 
introduced  in  1983  and  modified  in  1992  [57]  .  Reference 
[11,  sect.  6. 2. 2. 1.1]  states  that  mission  display  geo- 
situational  symbology  was  "designed  to  be  compatible  with 
the  specifications  for  Naval  Tactical  Display  Symbols  (NTDS) 
to  insure  compatibility  across  Navy  platforms."  In  keeping 
with  good  design  practices,  "an  evolutionary— as  opposed  to 
revolutionary"  [51]— was  employed  and  much  of  the  previous 
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display  symbology  was  preserved.  Having  its  roots  in  the 
1980s  display  technology,  NTDS  is  a  bare-bones  graphical 
display  in  which: 

All  the  on-screen  shape  coding  (including  the 
contact  and  track  shapes)  is  suggestive,  in  some 
way,  of  the  object  or  parameter  being  represented 
in  order  to  facilitate  operator  recognition.  The 
top  half  of  a  geometric  shape  represents  an  air 
contact,  an  entire  geometric  shape  represents  a 
surface  contact,  and  the  lower  half  of  a  shape 
represents  a  subsurface  contact.  .  The  SAR 
Reference  Point  is  the  same  shape  as  the  "man 
overboard"  Naval  signal  flag;  the  Pointer  symbol 
consists  of  an  arrow;  the  Torpedo  Splash  Point 
looks  like  a  torpedo  entering  the  water,  and  so 
on.  [11,  sect.  6. 2. 2. 1.1] 

Did  this  requirement  to  incorporate  an  existing 
design  per  step  three  of  [6]  unduly  influence  the  final 
navigation  display?  Considering  that  the  traditional 
navigation  display  of  older  U.S.  Navy  rotary-wing  aircraft 
consists  of  green  symbology  on  a  black  background  (TACNAV  of 
UH-3  first  introduced  in  the  1960s,  for  example)  ,  one  can 
compare  that  against  the  final  CC  design  of  Figure  17  and 
conclude  that  it  did. 
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Figure  17.  The  current  navigation  display  of  the  CC 

(From:  [11,  Keys  cockpit  interface  simulator]) . 


It  should  be  noted  that  the  MH-60S  ORD  does  not 
specifically  state  the  need  for  a  NTDS  type  display  for 
navigation  but  does  require  the  same  general  functionality 
per  [30,  sect.  4.6.7].  It  should  also  be  noted  that 
utilizing  the  NTDS  symbology  in  itself  is  not  a  bad  idea  as 
it  leverages  existing  user  knowledge.  However,  sticking 
with  the  exact  display  environment  despite  clear  potential 
for  improvement  could  be  considered  a  mistake. 

As  such,  it  can  be  argued  that  the  previous 
examples  reviewed  for  the  Common  Cockpit  are  so  far  removed 
from  an  all-glass  cockpit  that  their  inclusion  as  a  basis 

for  design  was  more  of  a  hindrance  than  help. 
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VI.  CONCLUSIONS,  RECOMMENDATIONS,  AND  FURTHER  STUDY 


A.  CONCLUSION 

On  paper,  Lockheed  Martin  met  every  functional 
requirement  specified  in  the  ORD  in  relation  to  the  Common 
Cockpit.  All  applicable  acquisitions  instructions  and 
design  methodologies  as  required  in  the  Department  of 
Defense  Directive  5000.1  were  followed.  The  cockpit  was 
tested,  evaluated  and  approved  by  the  Program  Manager  and 
delivered  to  the  user.  However,  based  on  the  results  of  the 
interview  summarized  in  Appendix  A  and  discussed  throughout 
this  thesis,  the  final  design  produced  overlooked  a  critical 
display  required  to  effectively  and  safely  perform 
navigation  tasks.  In  an  attempt  to  fill  this  void, 
acquisition  managers  implemented  a  strap— on  (kneeboard 
mounted)  moving  map  system  without  adequate  consideration  to 
the  usability  of  such  a  system.  The  result  of  this  piecemeal 
approach  to  a  moving  map  solution  is  the  MH-60  cockpit  in 
which  the  user  is  left  wanting.  How  did  this  happen? 
Perhaps  the  process  itself  is  to  blame. 

B.  APPLYING  CREW  CENTERED  DESIGN 

As  argued  above,  the  Lockheed  Martin  design 
methodology,  which  is  now  standardized  in  the  DoDAF 
methodology  [58],  is  inadequate  for  glass  cockpit  design. 
It  is  too  broad-based  and  does  not  adequately  capture  the 
essence  of  modern  cockpit  design.  This  failure  manifested 
itself  in  the  complete  lack  of  a  fully  integrated  moving 
map,  despite  the  functional  requirements  (even  with  the 
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exclusion  of  the  DMK  requirements)  and  well-documented 
benefits  to  the  aircrew  for  enhanced  situational  awareness. 
A  better  approach  would  be  to  detail  glass  cockpit 
specifics.  This  recommendation  is  discussed  in  the 

"Recommendations"  section  of  this  thesis. 

If  the  CCD  process  was  applied  to  the  Common  Cockpit 
requirements,  what  would  the  result  be?  Without  a  full 
implementation  of  CCD,  it  is  impossible  to  say.  However,  a 
brief  exploration  of  the  CCD  philosophy  with  regards  to  MH- 
60S  ORD  defined  functional  requirements  can  be  had  with  the 
following  assumptions: 

•  Step  one  of  the  CCD  process  (previous  design, 

production,  and  operational  experience,  technology 
constraints)  will  only  be  considered.  The  end  goal 
of  this  evaluation  is  simply  to  fulfill  the 

requirement  of  step  one  of  [6,  p.  9]  to  "generate  an 
operational  concept". 

•  The  latest  version  of  the  MH-60S  ORD  will  be 
considered  [30] . 

•  Current  technology  limitations  of  the  Common  Cockpit 

will  be  considered  but  will  not  be  a  limiting 
factor.  The  assumption  is  that  if  a  technology 

requirement  exists,  it  is  technology  feasible  to 
implement  in  the  current  common  cockpit  within 
reason . 

•  The  normal  manning  requirements  for  a  HCI  design 
team  for  step  one  is  made  up  solely  by  the  author. 
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1. 


Functional  Requirements  Evaluated 


As  discussed  above.  Common  Cockpit  functional 
requirements  are  scattered  throughout  the  MH-60S  ORD. 
Grouping  them  together  yields  the  following  composite 
requirement:  GATM  capable  (4.1.2);  Maneuver  the  helicopter 
along  a  desired/selected  track  (4. 2. 1.1);  kneeboard  moving 
map  which  is  usable  during  both  unaided  and  Night  Vision 
Device  (NVD)  flight  (4.3.9);  capability  to  preload  geo¬ 
navigation  waypoints  and  display,  display  the  pilots 
position  relative  to  surface  contacts  via  Global  Positioning 
System  (GPS)  (4.6.7) .  All  requirements  are  from  [30] . 

Even  without  the  inclusion  of  the  direct  requirement  to 
implement  a  kneeboard  moving  map  in  (4.3.9),  in  the  author's 
opinion,  the  sum  of  the  requirements,  as  well  as  practical 
experience  with  in-flight  navigations  in  the  form  of  paper 
charts,  would  lead  experienced  flight  crews  providing 
operational  experience  in  step  one  to  the  conclusion  that 
the  fundamental  task  being  accomplished  by  these  outlined 
functional  requirements  is  that  of  geo-positional 
situational  awareness  for  the  flight  crew. 

Finally,  there  are  a  host  of  considerations  in  choosing 
a  moving  map  including  perspective,  orientation  and  size. 
But  above  all  this  there  is  the  primary  consideration: 

A  primary  Naval  Air  Systems  Command  (NAVAIR)  goal 
in  specifying  the  new  system  is  to  enhance 
situational  awareness  (SA)  and  aircrew  mission 
effectiveness  without  further  burdening  pilot 
task  workload.  [59,  p.  1] 

It  is  by  this  guiding  requirement  that  the  operational 
concept  shall  be  defined. 
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2 .  Mapping  Options 


Now  that  the  functional  requirements  have  led  the 
generation  of  an  operational  concept  that  includes  a  moving 
map,  the  team  must  determine  what  kind  of  moving  map  should 
be  included.  This  is  a  job  for  the  knowledgeable  Human 
Factors  engineers  on  the  team. 

One  key  to  determining  map  orientation  may  be  the 
context  for  which  navigational  directions  are  presented. 
Per  [13,  p.  110],  "the  language  of  the  displays,  in  terms  of 
ego-referenced  directions  like  left,  right,  above  or  below, 
should  match  the  language  of  the  control  that  is  also 
typically  represented  in  such  ego-referenced  terms."  The 
team  should  assume  that  if  navigational  directions  are  given 
to  the  pilot  in  terms  of  ego-centric  commands  like  "turn 
left  in  10  seconds,"  then  the  map  orientation  should  be 
direction  up.  If  commands  are  in  the  form  of  "turn  north  to 
a  heading  of  350  degrees,"  then  north  up  is  a  more 

appropriate  directional  context  for  the  moving  map.  The 
previous  reference  is  known  as  ego-referenced  or  local 
guidance  while  the  later  is  world  referenced  or  global 
awareness  [13,  pp .  110,  113]. 

In  [13]  the  two  distinct  views  of  Ego-Referenced 
Framework  (ERF)  or  World-Referenced  Framework  (WRF)  are 
described.  Ego-Referenced  Frame  (ERF)  provides  the  "user 
centered"  view  in  which  the  view  is  presented  as  if  seen 

from  the  user's  eyes.  World-Referenced  Framework  (WRF)  is 
less  ecological  in  nature.  It  presents  a  view  in  which  the 
observer  is  able  to  orientate  himself  in  the  world  of 
reference.  It  is  a  view  in  which  the  ERF  is  just  one  part 

of  the  larger  world.  Since  Crew-Center  Design  places 
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emphasis  on  task  accomplishment  (in  this  case  navigation) , 
both  perspectives  will  be  viewed  by  the  specific  tasks  they 
accomplish . 

It  should  be  clarified  that  for  the  bulk  of  their 
discussion,  [13]  discusses  WRF  as  a  function  of  both  a 
three-dimensional  (3D)  and  two-dimensional  (2D)  display. 
For  the  purpose  of  this  thesis,  a  three-dimension 
representation  for  WRF  is  ruled  out  for  one  primary  reason: 
there  are  not  currently  enough  navigational  data  points  to 
present  any  WRF  operating  environment  in  3D.  It  should  be 
noted  that  there  is  no  reason  to  believe  that  a  3D 
environment  suitable  to  WRF  mapping  as  described  in  [13] 
could  not  be  constructed  in  the  near  future.  Both  airspace 
management,  as  well  as  operational  environments,  could  be 
modeled  in  3D,  much  as  they  are  for  simulators.  It  is 
realistic  to  anticipate  that  near  future  operating 
environments  will  be  mapped  in  3D,  much  as  Google  Earth  has 
done  by  converting  2D  imagery  into  3D  maps.  Therefore,  3D 
should  be  a  consideration  for  future  upgrade  plans. 

a.  Ego-referenced  Frame 

In  [13,  pp.  110-111]  ERF  is  described  as  "ego- 
referenced,  forward  viewing,  zoom  in,  and  3D."  ERF 
"mimic [s]  the  natural  viewing  of  human  observers  as  they 
walk  through  an  environment  [13,  p.  111]."  Ego-referenced 
refers  to  one  of  the  four  cardinal  eye  points  a  viewer  can 
have:  egocentric,  exocentric  perspective,  exocentric  2D  plan 
view  (Figure  17),  and  exocentric  2D  side  view  (Figure  18)  . 
For  the  purposes  of  this  discussion,  ego-referenced  and  ego¬ 
centric  are  the  same  viewpoints  as  depicted  in  Figures  18 
and  19. 
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Figure  18.  Egocentric,  Exocentric  perspective,  and 

Exocentric  Plan-view  displays  (From:  [12]) 


right  (After:  [13]) 
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b.  World-referenced  Frame 

It  can  be  stated  that  a  2D  plan-view  is  nothing 
more  than  a  specialized  case  of  a  3D  WRF  in  which  there  is 
no  of f-vertical-axis  view.  Per  [12],  the  2D  plan-view  is 
described  as  akin  to  the  3D  WRF  from  Figure  18,  but  "where 
the  viewpoint  is  90  degrees  to  the  world's  plane."  Despite 
the  conversion  from  the  3D  WRF  to  the  specialized  case  of 
2D,  the  three  fundamental  features  of  WRF  described  by  [13, 
p.  Ill]  are  still  valid: 

(a)  they  may  need  to  be  world-referenced  to 
support  communications  with  others  who  may  not 
share  the  same  momentary  ego-frame  of  reference; 

(b)  they  should  soon  out  or  be  wide  angle, 
representing  a  much  broader  region  of  the  world 
than  does  a  local  guidance  display;  and  (c)  the 
need  for  three  dimensionality  that  was  inherent 
in  local  guidance  displays  is  mitigated  by  the 
desirability  of  a  world-referenced  frame;  this  is 
because  a  3D  display  must  by  definition  assume  a 
particular  ego-referenced  azimuth  angle. 


3.  2D/3D  Solution 

Although  it  presents  some  very  unique  benefits  to 
geospatial  situational  awareness,  as  discussed  by  [13]  and 
[12],  3D  also  carries  with  it  some  significant  baggage  in 
today's  cockpit.  Three-dimensional  representations  would  be 
a  significant  perceptive  leap  from  the  2D  paper  charts  and 
video  displays  in  use  today  by  flight  crews.  This  may 
violate  the  "evolutionary,  as  opposed  to  revolutionary  [51]" 
construct  discussed  previously.  This  point  is  made  by  [13, 
p.  113]  : 
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Although  counterarguments  [for  2D  plan-view  maps] 
have  been  made  in  aviation  that  a  moving  aircraft 
or  stabilized  world  display  is  more  compatible 
with  the  pilot's  mental  model  of  the  aircraft 
system  (Johnson  &  Roscoe,  1972)  and  can  provide 
as  good  performance. 

It  may  also  be  limited  by  the  technical  limitations  of 
current  or  near  future  display  technology.  To  declare  3D  as 
the  primary  source  of  navigation  information  for  today' s 
Common  Cockpit  would  therefore  be  a  stretch  at  best.  To 
fully  recognize  the  benefits  of  3D,  a  Heads  Up  Display  (HUD) 
and  augmented  reality,  as  discussed  by  [12],  would  have  to 
be  considered.  This  extensive  modification  to  the  Common 
Cockpit  is  well  beyond  the  scope  of  this  thesis.  As  a 
secondary  source  of  geospatial  reference,  a  simplified 
version  of  a  3D  ERF  display  is  a  possibly,  as  will  be 
discussed  below. 

a.  2D  Moving  Map 

As  discussed  above,  the  benefits  of  a  2D  plan-view 
moving  map  are  undeniable.  The  question  then  arises  as  to 
what  features  this  moving  map  would  incorporate? 

Through  an  interview  of  both  fixed-wing  and 
rotary-wing  pilots  utilizing  several  types  of  2D  WRF  plan- 
view  maps  [59]  concluded  the  following: 

•  Context  switching  (time  to  switch  between 
different  map  views) :  "Faster  is  better 

accurately  sums  up  the  pilots'  preferences  with 
regard  to  all  three  time-to-switch  functions 
(switching  map  modes,  switching  chart  scales, 
and  command  lat [itude] /ion [gitude]  repositions 
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(p.  14) No  more  than  1  second  between  context 
switches  was  generally  acceptable  (Section 
4.1.3)  . 

•  Data  update  rates:  In  this  case,  faster  is  not 

better.  Pilots  preferred  15Hz  [updates  per 
second]  displays  over  20Hz  displays  (p.  14, 

Section  4.1.3) . 

•  Map  Positioning:  North-up,  track-up,  centered, 

and  decentered  were  considered.  Most  pilots 
found  that  more  often  than  not  that  track-up 
generally  proved  more  useful  than  north-up  but 
both  had  their  advantages  depending  on  the 
situation.  As  discussed  in  [59,  pp.  18,  19], 

pilots  accomplished  "certain  tasks  (e.g., 
reconnaissance)  more  effectively  with  a  north- 
up  map  (p  19) In  both  north-up  and  track-up, 
pilots  preferred  the  ability  to  determine 
whether  the  aircraft  was  centered  or  de¬ 
centered  and  to  what  degree  off  center  the 
aircraft  would  be  (Section  4.2.3) . 

•  Zooming:  The  ability  to  both  zoom-in  and  zoom- 
out  on  a  map  were  shown  to  be  beneficial.  Of 
particular  interest  is  the  quick  zoom-out 
capability  in  which  a  pilot  can  quickly  attain 
a  larger  global  situational  awareness  picture 
and  then  zoom-in  to  the  original  scale  with  a 
single  button  push  (Section  4.3.2). 

•  Vector  Moving  Map  Displays:  Vector  maps  can 
have  the  same  appearance  and  content  of  any 
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traditional  chart  but  instead  of  being  a 
digitally  scanned  picture  of  the  chart  are 
instead  digitally  rendered  such  that  scaling 
and  rotation  have  no  effect  on  readability. 
"Vector  maps  are  rendered  from  individually 
stored  objects  (p.  44).  These  objects  include 

anything  that  would  be  found  on  a  traditional 
map  "including  lines  (i.e.  roads),  points  with 
associated  symbols  (i.e.,  airports),  text 
features  (e.g.,  city  names),  and  areas  (i.e., 

shaded  metropolitan  areas)  (p.  44)  ."  Vector 

maps  can  also  be  modified  on  the  fly  by  adding 
symbology  and  objects  not  originally  found  on 
the  map.  It  was  concluded  by  [59]  that  the 
advantages  vector  maps  had  over  digitally 
scanned  maps  were  numerous.  Of  note  "virtually 
all  helicopter  pilots  gave  all  three 
capabilities  (keeping  text  upright,  selectively 
de-cluttering,  and  adding  detail)  the  highest 
possible  rating  (extremely  useful)  [p.  45, 

sect .  4.6.2]. 

Map  sources  should  include  all  navigational  charts 
(including  Digital  Aeronautical  Flight  Information  File 
(DAFIF)  data)  and  tactical  charts  currently  available  to 

aircrew.  In  addition,  satellite  imagery  should  be  included 
to  capture  areas  not  covered  by  existing  charts.  A  hybrid 
between  both  types  of  maps  would  be  ideal  in  order  to 

provide  the  pilot  with  the  maximum  amount  of  geographical 

data  available.  The  hybrid  feature  found  on  many  on-line 
mapping  tools  such  as  MapQuest  ©  and  Google  Earth  ©  provide 
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excellent  examples  of  this  concept.  These  functional 
requirements  are  outlined  in  section  4.3.9  of  [30]: 

Moving-map  shall  be  capable  of  pre-flight  loading 
and  in-flight  display  of  National  Geospatial- 
Intelligence  Agency  (NGA)  raster  product  format 
data  and  vector  data  that  incorporates  and 
overlays  geo-referenced  navigation  and 
waypoint/f  light  data  onto  a  common  map 
background . 

The  MFD  moving  map  design  described  above  has  many 
traits  in  common  with  the  current  DMK  implementation.  This 
follows  as  much  of  the  functional  requirements  of  a  MFD 
integrated  moving  map  are  found  in  the  DMK.  Thus,  in 
keeping  with  the  philosophy  of  leveraging  existing 
"engineering  experiences  [6,  p.  26]"  when  developing  new 
designs,  the  DMK  interface  will  be  used  as  a  basis.  The 
reader  should  keep  in  mind  that  interview  complaints  about 
the  DMK  had  more  to  do  with  the  kneeboard  implementation 
than  the  actual  interface.  That  said,  a  one-for-one  copy  of 
the  DMK  interface  is  not  the  solution.  A  more  specific 
interview  on  the  likes  and  dislikes  of  the  DMK  interface 
should  be  conducted  to  eliminate  the  wheat  from  the  chaff 
and  identify  any  interface  issues. 

Inclusion  of  the  DMK  interface  in  the  design 
concept  also  brings  in  to  play  FalconView©.  Just  like  the 
reuse  of  DMK  in  order  to  leverage  existing  aircrew  training, 
this  system  will  be  based  on  FalconView©  and  Portable  Flight 
Planning  Software  (PFPS)  commonly  in  use  throughout  military 
aviation.  FalconView©: 

Is  a  non-proprietary  GOTS  (Government  Off-The- 
Shelf)  application  for  analyzing  and  displaying 
geographical  data  crucial  to  the  warfighter.  Its 
ease  of  use  and  wide  variety  of  applications  have 
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made  it  the  system  of  choice  for  the  warfighter 
and  the  standard  for  data  interchange  in  Iraq  and 
Afghanistan.  [60,  p.  1] 

The  primary  benefit  of  FalconView©  is  it  "supports 
a  robust  set  of  programmer  interfaces,  which  allow  diverse 
applications  to  fuse  their  information  into  a  single 
coherent  picture  of  the  user's  area  of  interest  [60,  p.  2]." 
Areas  of  interest  could  include  a  benign  flight  across  the 
United  States  or  a  more  hostile  flight  in  to  enemy 
territory.  Either  way  it  is  captured.  The  ability  to  port 
this  data  directly  to  a  moving  map  display  is  extremely 
useful  and  is  without  doubt  the  primary  motivation  behind 
its  usage  on  the  DMK.  Using  FalconView  ©  is  also  in  keeping 
with  the  spirit  of  incorporating  "evolutionary— as  opposed  to 
revolutionary  [51]  changes  in  the  cockpit. 

One  major  issue  with  integrating  FalconView©  into 
the  MFD  moving  map  solution  is  the  question  of  in-flight 
planning.  Since  the  DMK  is  a  fully  functioning  native 
Windows  XP©  operating  environment,  there  is  a  one-to-one 
mapping  of  FalconView©  usability  from  the  PFPS  laptops  in 
the  squadron  to  the  DMK  in  the  aircraft.  The  operating 
environment  and  user  interface  devices  in  the  common  cockpit 
are  significantly  different  and  present  a  challenge  to  the 
functionality  of  in-flight  user  updates.  Although  this 
functionality  was  not  specifically  identified  in  the  MH-60S 
ORD,  it  is  an  issue  that  must  be  addressed.  The  primary 
issue  is  therefore  whether  a  technical  limitation  exists  in 
the  cockpit  environment  that  would  prevent  all  of  the 
FalconView©  flight  planning  functionality  from  being 
available.  This  would  warrant  a  closer  examination  and  is 
beyond  the  scope  of  this  thesis.  To  that  end  the  assumption 
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will  be  made  that  at  least  limited  flight  planning 
functionality  is  available  in  the  MFD  moving  map  design  as 
detailed  in  the  existing  functional  requirements  from 
section  4.6.7  in  which  the  system  shall  "provide  the  ability 
to  manipulate  these  waypoints/flight  plans  in  flight." 

b.  3D  ERF  FLIR 

A  more  radical  design  departure  from  the  current 
common  cockpit  convention  would  be  the  integration  of  a 
pseudo  3D  ERF  display  to  assist  the  non-flying  pilot  with 
Geo-positional  situational  awareness.  This  design  would  be 
pseudo  in  the  fact  that  true  3D  would  is  technically  limited 
in  the  current  common  cockpit.  The  goal  is  to  attempt  to 
capture  a  more  ego-referenced  display  since  " (ego 
referenced)  maps  support  better  navigation  performance,  as 
these  tend  to  both  to  alleviate  mental  rotation  and  provide 
a  left-right  display  frame  of  reference  that  is  compatible 
and  congruent  with  the  frame  of  reference  of  the  control" 
[13,  p.  113] . 

A  true  3D  ego-centric  ERF  display  would  most 
likely  involve  the  projection  of  a  3D  environment  on  some 
type  of  heads-up  display,  as  described  in  [12] . 
Acknowledging  realistic  technical  limitations,  the  goal  of 
this  ERF  implementation  would  be  to  assist  the  non-flying 
pilot  with  navigational  reference  under  the  assumption  that 
he  or  she  would  be  "backing  up"  the  flying  pilot  as  is  often 
the  case  in  high  workload  cockpit  environments . 
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The  operating  environment  for  this  implementation 
would  be  in  a  tactical  situation  in  which  local  guidance  is 
the  preferred  means  of  navigation  as  outlined  in  [59]  .  Such 
missions  include  NVD  Nap-of-the-Earth  (NOE)  flights,  as  well 
as  overwater  surveillance  missions. 

The  design  would  superimpose  current  HUD  symbology 
found  on  the  NVD  kit  to  the  MFD  FLIR  image.  The  FLIR  image 
data  would  provide  the  ego-centric  view  found  associated 
with  a  3D  ERF  while  the  HUD  projection  would  help  the  non¬ 
flying  pilot  reference  the  current  condition  of  the 
aircraft.  This  display  would  thus  provide  both  geo- 
positional  data  as  well  as  aircraft  status  in  one  glance. 
The  reason  this  data  would  be  designed  for  the  non-flying 
pilot  is  that  the  majority  of  the  viewing  is  done  while 
scanning  inside  the  aircraft  (MFD  scan)  and  not  outside  as 
is  the  case  for  tactical  environments. 

The  inclusion  of  this  functionality  has  the  added 
benefit  of  including  both  the  ERF  and  WRF  perspectives.  As 
discussed  in  [12]  and  [13],  this  is  the  ideal  solution. 

4 .  Symbology  and  Color  Scheme 

The  Department  of  Defense  Interface  Standard— Aircraft 
Display  Symbology  (MIL-STD-17 87C)  is  the  standard  for 
display  symbology  throughout  the  Department  of  Defense.  It: 

Defines  the  symbology  requirements  for  a  primary 
flight  reference  and  describes  some  fundamental 
relationships  between  symbol  motion  and  aircraft 
system  states.  It  describes  symbols,  symbol 
formats,  and  information  content  for  electro- 
optical  displays  that  provide  aircrew  members 
with  information  for  takeoff,  navigation,  terrain 


72 


f ollowing/terrain  avoidance,  weapon  delivery,  and 
landing.  It  also  provides  (in  appendixes)  non¬ 
binding  information  on  symbolgy,  geometry,  fonts, 
recommended  dimensions,  and  mechanizations.  [61, 
p.  1] 

Given  the  depth  and  breadth  of  this  document,  the 
design  team  will  use  it  as  the  standard  for  display 
symbology . 

C .  RECOMMENDATIONS 

The  intended  scope  of  this  thesis  is  an  examination  of 
the  Common  Cockpit  associated  with  the  MH-60S  and  MH-60R  and 
recommendations  on  the  improvement  of  that  program  will  be 
made.  Some  of  these  recommendations,  however,  are  more 
broad-based  and  applicable  to  the  entire  defense 
acquisitions  process  outlined  in  [62],  as  it  relates  to 
glass-cockpit  design.  Recommendations  are  thus  divided  into 
these  two  categories . 

1 .  Common  Cockpit  Recommendations 

The  author  is  keenly  aware  that  in  reality  the  chance 
of  a  complete  redesign  of  the  Common  Cockpit  due  to  cost 
alone  is  slim.  In  relation  to  "trade-offs"  with  the  current 
common  cockpit,  cost  would  seem  the  only  issue  as  the  basic 
technological  requirements  are  already  in  place.  Realistic 
recommendations  are  thus: 

Implement  a  moving  map:  Nine  of  nine  pilots  interviewed 
said  an  integrated  MFD  moving  map  would  greatly  improve  geo¬ 
spatial  situational  awareness  during  every  aspect  of  flight 
regardless  of  mission.  NAVAIR  as  well  recognized  this  fact 
and  developed  the  practically  useless  DMK  as  noted  earlier. 
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Considering  the  positive  impact  a  truly  MFD  integrated 
moving  map  would  have,  NAVAIR  should  expedite  this  design 
well  ahead  of  the  current  plan  to  field  it  in  2016,  assuming 
it  gets  funded  [35]  .  It  should  be  noted  that  Lockheed 
Martin,  as  a  result  of  the  IRAD  discussed  above,  has  already 
developed  a  prototype  moving  map  that  integrates  graphical 
map  overlays  (navigational  maps,  etc.)  with  the  existing 
NTDS  style  symbology  found  in  the  current  Common  Cockpit. 

Reprogram  the  Common  Cockpit:  Elevate  the  Common 
Cockpit  program  to  an  Acquisitions  Category  (ACAT)  instead 
of  its  current  845  status.  This  will  help  ensure 
requirements  are  clearly  stated  and  allow  better  management 
of  costs  and  funding. 

2 .  Defense  Acquisitions  Recommendations 

Implement  Crew  Centered  Design  in  the  DoD  acquisitions 
process:  In  today's  modern  computer  centric  aircraft, 
reliability  of  the  aircraft  as  a  system  is  rapidly  being 
overshadowed  by  usability  as  the  number  one  design  issue. 
Appendix  eight  of  [62]  clearly  recognizes  this  shift  and 
states  the  Program  Manager  of  a  DoD  acquisitions  program: 

Shall  have  a  plan  for  [Human  Systems  Integration 
(HSI)]  in  place  early  in  the  acquisition  process 
to  optimize  total  system  performance,  minimize 
total  ownership  costs,  and  ensure  that  the  system 
is  built  to  accommodate  the  characteristics  of 
the  user  population  that  will  operate,  maintain, 
and  support  the  system,  [p.  60] 

Enclosure  eight  continues  by  discussing  a  broad  range 
of  issued  including  training  and  survivability.  Although 
necessary  at  a  high  level,  this  broad-brush  approach  to  HSI 

is  insufficient  when  dealing  with  cockpit  design, 
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evidenced  by  the  Common  Cockpit.  Given  the  complexity  of 
the  modern  cockpit,  associated  pilot  workload  and  the 
uniqueness  of  the  cockpit  operating  environment,  a  very 
specific  methodology  must  be  outlined  to  address  its  design 
and  implementation.  To  this  end  [62]  should  specifically 
name  Crew  Centered  Design  as  the  sole  method  of  manned 
cockpit  design. 

Refine  ORDs  to  be  as  specific  as  possible  to  reflect 
user  needs:  Ensure  that  Operation  Requirements  Documents 
(ORD)  or  Initial  Capabilities  Documents  (ICD)  as  described 
in  [62]  are  written  as  clear  and  concise  as  possible. 
Functional  requirements  should  be  justified  via  sound 
scientific  methods  and  well  understood  by  the  Program 
Manager.  Acquisitions  professionals  should  understand  that 
the  contractor  is  bound  by  the  contract  to  provide  what  is 
asked  for,  not  necessarily  what  is  needed. 

Combine  efforts  across  DoD  to  produce  a  truly  Common 
Cockpit:  Expand  the  notion  of  cross  platform  cockpit 
commonality  by  following  the  example  of  the  U.S.  Army's 
Common  Avionics  Architecture  System  (CAAS) ,  in  which  the 
same  basic  cockpit  architecture  is  used  in  the  Army' s 
extensive  fleet  of  dissimilar  rotary-wing  aircraft.  By 
combining  resources  and  leveraging  the  existing  development 
experience,  the  Navy  can  make  the  next  generation  of  Common 
Cockpit  truly  common  by  employing  it  across  all  new 
Navy/Marine  Corps  rotary-wing  aircraft.  This  is  not  to  say 
there  will  not  be  differences  between  cockpits,  but  it  is  an 
acknowledgement  that  the  fundamentals  of  aviate ,  navigate , 
communicate  are  common  functional  requirements  of  any 
cockpit . 
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Examine  the  integration  of  Human  System  Integration 
across  all  acquisitions  projects  that  have  human-machine 
interactions:  Although  this  thesis  is  specific  to  the 

Common  Cockpit,  this  issue  is  just  one  example  of  the  much 
broader  issue  of  usability  across  all  human-machine 
interaction.  HSI  applies  as  much  to  cockpits  as  it  does  to 
any  type  of  device  that  requires  direct  human  interaction. 
In  fact,  the  fundamental  usability  of  a  cockpit  is  not  that 
much  different  than  that  of  a  door  handle:  the  design  must 
be  usable  or  it  will  not  get  used.  Through  the  use  of 
methodologies  such  as  CCD  briefly  described  in  this  thesis, 
the  acquisitions  process  must  seek  proven  and  effective  ways 
to  integrate  HSI  with  existing  industry  design  practices  and 
standards  for  the  HSI  requirements  of  [62]  to  become  truly 
effective . 

D .  FUTURE  WORK 

During  the  interview  conducted  in  San  Diego, 
respondents  identified  two  potential  areas  of  research  in  to 
Common  Cockpit  shortcoming.  These  include: 

•  Two  interview  subjects  recommended  the  integration 
of  a  Flight  Management  System  for  improved  airway 
navigation.  An  example  of  this  is  Sikorsky's  glass 
cockpit  solution  and  with  an  integrated  FMS  800 
[63]  . 

•  Five  of  nine  interview  subjects  indicated 

dissatisfaction  with  the  several  aspects  of  the 
Forward  Looking  Infrared  (FLIR)  implementation  to 
include  image  display  size  and  the  usefulness  of  the 
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Hand  Control  Unit  (HCU) .  Further  exploration  in 
this  direction  is  warranted. 

•  Four  of  nine  pilots  interviewed  expressed  some  level 
of  dissatisfaction  with  the  current  PKI  /  FFK  layout 
and  menu  depth  associated  with  these  keys.  Further 
exploration  in  to  the  usability  of  the  current  setup 
against  the  guidelines  established  in  NAWCADPAX 
"Situational  Awareness  Guidelines . " 

•  Explore  the  possibility  of  an  ego-centric  3D 
augmented  reality  HUD  for  the  Common  Cockpit. 
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APPENDIX  A:  INTERVIEW  RESULTS  SUMMARY 


Nine  subjects  were  interviewed  over  a  three-day  period. 
Although  scheduled  to  last  one  half  of  an  hour,  the 
interviews  lasted  on  average  an  hour.  A  summary  of 
questions  asked  in  Appendix  A  are  provided  below. 

A.  SUMMARY  STATISTICS 

•  Total  hours  (median) :  1300 

•  Total  MH-60S  hours  (median) :  1000 

•  Total  previous  qualified  Helicopter  in  a  different 
series:  2 

B .  QUESTION  SUMMARIES 

The  following  represents  a  summary  of  the  questions 
asked  during  the  interview  process.  Although  some  themes 
were  common  throughout  the  interviews,  some  subjects  brought 
out  unique  ideas  and  observations . 

1.  What  MH-60S  missions  are  you  most  familiar  with? 
(SAR,  LOG,  MEDEVAC,  etc.): 

All  the  subjects  were  familiar  with  the  basic  FRS 
missions,  including  Search  and  Rescue  (SAR) ,  Logistics 
(LOG), and  basic  flight  familiarity  training  (FAM) .  All  were 
also  familiar  with  Armed  Helo  mission  (TACTICS) ,  although 
the  experience  level  varied  from  entry  level  to  advanced. 
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2. 


Given  your  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you 
may  have  experienced  difficulties  with  the  cockpit 
interface  while  conducting  those  missions : 

A  wide  variety  of  issues  where  presented.  Concepts  are 
grouped  below: 

•  Multifunction  Display  (MFD)  readability:  Initial 

boot  contrast  defaults  to  the  lowest  setting  thus 
requiring  the  user  to  adjust  contrast  to  a  higher 
setting  to  be  readable.  Also,  several  magenta 
colored  displays  (needles  and  heading  settings)  were 
not  readable,  particularly  on  the  edges  of  the 
viewing  area. 

•  Forward  Looking  Infrared  (FLIR)  Hand  Control  Unit 
(HCU) : 

•  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 

•  Likes 

•  The  joystick  interface  pointing  device  was  mentioned 
as  effective.  However,  the  variable  rate  in  which 
scroll  rate  is  somewhat  proportional  to  joystick 
displacement  took  practice  to  master. 

•  Dislikes 

•  Layered  menus  were  almost  universally  mentioned  as 
an  issue.  Specifically  mentioned  was  the  three  step 
process  of  switching  the  IFF  transponder  from 
"Transmit"  to  "Standby." 
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3.  Are  there  any  other  MH-60S  interface  issues  that 
you  would  like  to  describe  or  may  be  relevant  to 
this  study? 

This  question  almost  completely  revolved  around  the 
elimination  of  the  current  kneeboard  implementation  of  the 
moving  map  functionality  and  replacing  it  with  an  integrated 
moving  map  display  in  the  Mission  Display  (MD) . 

4.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

By  the  end  of  the  interview  process,  this  question  was 
both  asked  and  answered  as  a  result  of  discussions  from 
questions  c  and  d  above.  However,  a  few  subjects  mentioned 
other  items  not  previously  discussed  during  their  interview, 
including  the  need  for  more  comfortable  pilot  seats,  better 
visibility  from  the  cockpit,  and  unified  helmet  cord  that 
integrates  Internal  Communications  Systems  (ICS)  and  all 
Night  Vision  Device  (NVD)  functionality.  Also  mentioned  was 
changing  the  airspeed  indication  tape  to  a  more  readable 
format  and  a  way  for  aircrewmen  to  monitor  aircraft  altitude 
in  low-level  situations. 
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APPENDIX  B:  RAW  INTERVIEW  DATA 
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Once  the  interview  is  complete,  the  interviewer  will 
thank  the  participant  for  his  or  her  time  and  ask  if  there 
are  any  follow-on  questions. 
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II.  INTERVIEW  DATA  COLLECTION 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  275" 

2.  Total  hours  (MH-60S) :  (oo 

3.  Previous  model  qualified  HAC?:  jdo  ( /w/-  /MC 

B .  QUESTIONS 

1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) : 
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2.  Given  you  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions: 

.  'J/jcT  rtf(c,ui(  uw*  Ay'  fad  nfax*} 

-r d  Cot  cJa€cJ{  jk 

/  ^es  Jb#  v|an  "  ^  ? m 

3.  What  are  your  general  likes  and  dislikes  with  the' 
cockpit  interface? 

Likes:  » 

-  Hsx  fv\oclcA  0/1AP  (  e  Aj 

~  (joA  cdo  cjf  (-IsX.  /  AH-  /g^o 
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Dislikes : 


/\ (As/  yd*  f 


(Vo  jA-ifftvfa 


■/  h'J  (J±  U  o^y 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 


_  fJ?  id  (r-  d/sf^ys 

-  p<l  9-^  ^  Stf  ° 

~  fHdrt  CMslUjL-  ^  oaf 

5.  Finally,  if  there  was  something  you  could 


change 


about  the  cockpit,  what  would  it  be? 


-  -ih  i)i itbtl'ly 

-  Cht  Orel  £r  c«ryt*-fr  ^  / 


4 
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Yf^Oj~  ^  s,bY 

_  (4/  dfsff0f 

fAo^t  Mi  37^/  ^  ^/y  » 

Z-  Ykr^U^i  bh  *'“W  " 

~U lW  /  p 

4t>  fA\ V'^^y 

Pp  /  J  M  ,J  UQ  C  f'OAer  uhcr/-  or 

~  h  /ijU  C<y>  t- 

r  ./  \ 


u  '  Ip  f 

(JPS  aflp^cJ  /  ffcfr  ([oh 


-  UW  ‘  j  Ik  'plJ'tot'"* 

-<f(rfL  0^>l  !>;f  “  X 

-  bhh  W-f  /W  P  P  /;k  ^ 


/ 
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II.  INTERVIEW  DATA  COLLECTION 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  Qb 

2.  Total  hours  (MH-60S)  :  ^£>0 

3.  Previous  model  qualified  HAC?:  jijQ 

B .  QUESTIONS 

1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) : 


2.  Given  you  experience  in  the  above  missions  you 

highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions:  /  /  / 

la  kr  Ftzfl  -  is  /W  to 

h  Ct  X  'WW  j  ob  (At y  ck  ,  fak-  ^ 

/hu^t.  fifrc.  Y 

3.  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 

Likes :  Ce?/or  /VfWaA  <jv/~  tncfc&t-uns 

3 
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Dislikes : 

-  ^KZ- 

-  fJo  ^ 

Pc.Mlf’  <S <rr/  Caj?*l-.ty  UJtl  * 

br'.cft 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 

u  /he...  u-fojf  err  of 


-  fltouiy. 

h  ^  ^  l&U  Of/>r^ 

Jp  &r&r  '  S*' 

// 

'f'ueft-  cUi^ 


5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

■M-  ^  a 

/ifrM  -  /^A,  ■'A  6  rctk^  S°u^ ' 

Xw,  ^  ^ 

-  f\uO 
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o,„,  Ic^t  A  1°* 

,,  r(t^  ^  ^  ^  CtJ'r 
« iUr  *  ^  £^- 


^  ^ior  <,*£,/  /rfy.A/  /ito-A-f- 

X'tl  *>■*  ^ 


T*ml  &x 


WCh-  Ca,fo~  Ut-  *?  +*> 

CoJ --  ^  ^  ^ 


ffcO  .  . 

/mD  <^4^1 ca^A 
■  f\-y\o  Coord  rr"'f0'~'  ^ 

jk/W  ^  s^f  ^  f 


J.  fvO 

AHst^  . 

cs  fois  i 

j 

oCrcC'  ^cu&r^ 

^e_  / 

q/  <^JJ 

4^ 

i/^0-  U^_ 

T/4lT  /M0‘/"^'  ^P 

fOfL  €/^urx^ 
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II.  INTERVIEW  DATA  COLLECTION 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  1360 

2.  Total  hours  (MH-60S)  :  fO0>0 

3.  Previous  model  qualified  HAC?:  JUO 

B .  QUESTIONS 

1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) :  - 

^/W  ^  /  sA\L , 


2.  Given  you  experience  in  the  above  missions  you 

highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions:  , 

/Vu^Ao  ^  oe  ^  ^  +hl  o^r^cT' 

~  ftrfk  cUf'-y  ~foc>  swU  sk^hf  ^ 

_  u/t/1  ^rf  </  U  ,  cVr‘'t,/  Ff*- 

3.  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 

Llkes:  (j>l0rj  A)r~  Uxr-rir^i  / Cc^tJu^S 

(  6>lorS  3 

-dlgA/  ^  /  lo(o/’: lk'  rA^W-,  /if-  /(yy_ 

UCA  Vcre^O  f  jfwQ  d  Cyt/d 

•iSilfcA  cr^  6>//£c/de_ 
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Dislikes:  /L'1)A 

-  /It -t  <Z^O'dA  ~  /Ma^' 

jcc*~  0‘p*6}i'fy  ^ 

^joh  M  S*^'^ 


o/-  ^yff^ 
fZco<  t4>  ^ 

(foc^ 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 

Co^f^  ** 

Adt  u£rY 

%*((  .Ifft+rt-  Co*ir»( 

9&*  •*>  (oJT> ^  ^  c0UJ ° 

5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

5/w-,/V  ^  S^e(c^ 


4 
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1(V« 


(  SAfl  h&yS  CkT&nif 


f 


hcizs 


£rf.'^  U.cti  /"  ^  ier>i 

tya  U(  ^  j"a 

f\FCS  O.US  ^vkr  raJ"^  ^ 

/ho^'  d‘sfb/ 

f-.^  iAk^-k/  ~b  sM&*r'  J^ff7 

2^«~/  w  ^  ea  ^  ^'f,<-‘ 


7  Cutty  fi&p 


WW  ^SP  ^  ^ 

,>|u  ^ 

Jdlty  ddS 


U 


'  ‘Co 


,/plCicA 


-  Pq  /Yocy  £.c^cti  -fo  ^Ae.  tt-lYY  I 

SulU  b>o  °f^ 

"  C^c  e(^>V^  S^ep-C  On  b»(L 

{YlYZd  /V 


Yf)Y  -  yuh  dUp^  ^  tycr<^  y^ecY 

&V  /\Pcs  cc.<6e_ 

(j T^fty  tycr  h/S)k  -/^C^  bujYn-i  -Y>  b-  ^ v ^  ^ 
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II.  INTERVIEW  DATA  COLLECTION 


A. 


B. 


FLIGHT  EXPEREINCE 

1.  Total  hours:  \Vo 

2.  Total  hours  (MH-60S)  : 

6>& 


3.  Previous  model 

questions 


qualified  HAC?: 


1.  What  MH-60S  missions  are  you  most 
(SAR,  LOG,  MEDEVAC,  etc)  : 

l-Mo 


familiar  with 


2.  Given  you  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions: 

uw  fuik 

/ax/jl  ,#>  -'-v 

off-  /w  -A  Syiife-  ,  cf^ 

/A''"!  /t.Mi&'-f-or y  Jfonj  /Oyfc-f 

(froLtU  -  d-<yy_  fir  S«At/ 

3.  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 


5 

Cr-cC  error-  (k-ot/op  ,  c/t,  J 

-4  Orel 


S-tems 


9 


—jp ^  {Lt.  Itsv/h  cbestfc-  4^  ^ 

fu^i  r^/e'-c  ~  3  <4^  ^  *■ 

_  pzqfl  ^  £<yk  /Kt  (AR/V^Af). 
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6faer 


Dislikes:  / 

h  Mf  i  ^**4#-  is  Jn 

~}fu£:  gulef  & 

-  ua  ffiM  ^  3*^'  cft¥cl  ar€-t  c!^fft¥L ) 

.  farc  M  ^/&"  lJJ6/  J 


((Lus**J 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 

_  ^Cl a  ¥  ci^ <y? ^ d"- A y  clu^hy  , 

c6  Z  ^/ytfs  v >?* 

/r^f  lG  ^3 1 


5.  Finally,  if  there  was  something  you  could  change 


about 


the  cockpit,  what  would  it  be?  . 

~h  ^icc-t  <^frcY  (Iff,  6W 


( (cm 

also  ^y  l 


&  tu,  a  ^  C^kr.  Hv 

Ft  ft  to  **H  Cl^y  W 


4 
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,  [lt  ^  0^rr^(t 


o~cl  ^T' 


fal  5Vi^  o^il/  '  4ies 


M  /^ 


8°; 

f/C  {dry 


••/i>  /c  /-O  oo  -/^- 


4,.  Cat 


/;^:  9/  Jhfk/'t 


/i^fr  t/A^  ^ 


67^  ^ 


<jT 


"  ^Cl^rJ  °*  -S<~  ”iW  <W 

0y{  lt*A-  M4**  C>f,C<L 
__  ,.^1  rs-4s^h  A>J-  u^4l.  ,  A*-  M 

L^.  ^  ^  ^ 

"tfl  cUUJi  *'*/,v* 

,^fr  fiuO  i^/  •  AJ 

/,»  or  r^+  ■!»  ^'J  /W 


^pi>  offro^ 


'ofhjjd/-  £,j 


■%-  (sthf*  u  oi  4^/^  c^f  c* 

l/cu  y’+'^>  * 

„  r^O  ~  r,+  I^J  k^el  cl  fvJ^yy^ 

Ui°  W<W 
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II.  INTERVIEW  DATA  COLLECTION 


A. 


B. 


FLIGHT  EXPEREINCE 

1.  Total  hours:  IYJ© 

2.  Total  hours  (MH-60S):  [^2~OC) 

3.  Previous  model  qualified  HAC?: 

QUESTIONS 


1.  What  MH-60S  missions 
{SAR,  LOG,  MEDEVAC,  etc) : 


GAP,  Lo(s 

/ 


are 


you  most 


familiar  with 


2.  Given  you  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions: 

Stk-  Gy  Ac/  fUusV~  -  DR  is  rdr  L  $ cJr  aii 

0acl  AO^ec/  ffw-  tc-ivA  j)^,oo 

wt,  ir^  ^  '"A  '  °  °1''t 

t  -  fUtfd  v-  ,  Cte  +»  ^ 

u~  3.  Wnat  are  your  general  likes  and  dislikes  with  the 

cockpit  interface? 

Likes : 


3 
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Dislikes : 


M ytl4lfk_  Aey'J-^ 


SaM-*3'*' 

l^c/y 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 


-  pM  C£A_s  Grt- 

-fk  trfi  M 

V  O^cl  C  o 


Iap^c(  use  ^  Co^  Ue 

Cd  Hi'ct  ^  d 


5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

— d  k/up  Wj  -fo  cQAJf  P^A  ScHrft-s- 


4 
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(Ui\  U<r  d  d 

1  yZ  r>t(  & 


iUoon  ^ftf  '  ^c(  ^ 

-  ^Uiw^  chdc  scr^  jd 

-  look  '{"A  ['hc  I 

fectuaL-  rdd^  °~  fbjw 


id  fat  Yjt  o 
/■V  fK<^^ 

wu//  q/^o 
£,k»jf± 


_  77  d^ffcy  cf°t±  Ad 

dt(-rad  £-to~  i'Vcv'  ■pc>r/cr^ 

-k^kU  M«f  «<*  f/dt£~  %,H 

-j-ljt  i^y  f  cfdr'^  £d* 

{JcilvtL-  -V  /">""*/ 


Scd,  (po/ks>n  /  /)0 

CT^r-C^ 


II.  INTERVIEW  DATA  COLLECTION 


UfJ° 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  \^SO 

2.  Total  hours  (MH-60S) :  ^ 

3.  Previous  model  qualified  HAC?:  ^0 

B .  QUESTIONS 

1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) :  0 

H C T&PJ  /f^1  / 

0.17L-  o^Y  ''jW  ■) 

^  o s  's*7  s-<=“V 


2.  Given  you  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions: 

Agr  h*r<(  0^1  0^7  r>(N-  ^  bJ'  S  ^  £iiL 

d-  jftpr'fo 

V*'  ^ 


Oj  A/w  lmk«c{  -f‘fc>h  do**  0J,t  ^l*cc' 
^  I  f  ,  ,  /  I.aLi 


-7>  Cfof7  tyf*3  ^ 


3.  What  are  your  general  likes  and  dislikes  with  the 


cockpit  interface? 
Likes : 


3 
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Dislikes: 

h-kr&cc. 

j^ACN  1^—  FAA^  U)\Xi(c/ 

ixiz-l  by 


^l  Fcnft-  ,  (u^ 

fcA/L 

ru)k^  e-wyfkf-  OA 


A 

Tf\cr 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 


Ljo^ld  be  €Gner  -A-  yc^/v. 


5.  Finally,  if  there  was  something  you  could 
about  the  cockpit,  what  would  it  be? 

-fo  ■*'e^ 


change 

Oftr 


4 
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~  flclel  ^,snA  lf&r***' is 

(ft -60  to /l-  u^®  e^~f6i) 

-  ’Qnft  1 1  -WKiiw'  :^ty  /ii+  />'“'"  a'spfoyr 

/  ^  r  / 

^1/1 /"/6  5  A  6^  nu^Qh-'  -  /oil  of  &i*j2f 

Mf>  w<”'/  A  1C  «r r 

.  fry  fa, f-  £>  "lt  ^  ^  ^ 


k/ 
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II.  INTERVIEW  DATA  COLLECTION 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  l 

2.  Total  hours  (MH-60S)  :  [OOO 

3.  Previous  model  qualified  HAC? :  fUo 

B .  QUESTIONS 

1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) : 

icGr(  SA^,  TAP's, 


2.  Given  you  experience  in  the  above  missions  you 

highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions:  *  _/  _ 

pfcL  hi  o  'TV  ^/TMt  ■  S/cM 

-  flfroo  t(cy  j)G'(  0^  ph>j:  (jMj>  t,cafej  ffK 

SftfL-  fFk  For  C/S \f-  ffc  fkr^J 

~  QoW  cfcy/^c  Sftft- 

Q4JL  T^c  ^c£>  W 

-jUCG  l>rA 

3.  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 


»  r»+0 


p/iGo  Ce/YP?/;,r-)J 


Likes : 

__  tk+fbo  dot 1  (oh  c/  •Sfu/th 

„Tu(u6  frevS  /, 

^  tHJju  am.  ^Jej  u-.  cyd'C 


-  Put 
\uxuU 

<V  cyc/ic 
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A'/'*  Sa~ 


,  /jvd  H«£> 

q  J  /*—  ^ 

(JW/V  ^ 

-  QejpsS-  <b**^y'  ^ 


fo  ^/o*  ^ 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 

-W  ^  ° 


5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

txfkr  wan*/ 


4 
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(  o  ( 

/"vf  '>p/ i OCcl^ 

■or  /  />  '■ 

/^/J> 

/f  ^ 

/  f 

4  Iffj-t 

))fv-C]A 

j  6-0 

yo  0i£> 

/ 

\  Or*}/ 

-,-,  /1/W1U 

-  (n>$> 

/  6d 

fa+- 

)rs  )c„o*J6 

Cx  * 

_  uMp 

/j^rlro  1 

hoi 

'phT's  (fe 

Hy 

(  h'/^ 

</i-e 

Je-^iL,  t> 

■^-i  0  ficto 

piets  Myi 

g 

Crt. 

odifytf. 

-  {hl° 

$€0^ u  ~/x> 

Ue^4>'po 

A'd/Z  C  /W. 

f 

rdiUe/oy- 

h 

yb^  *4~o 

Coi-A/p>i 

j?Ao  - 

M&Lr  jl'P 

'/■£  [ypfii 

y '  I^AtT  rfujp  ^ 

- 

i 

i 

/H46 

^Utr  0~‘/  /> 

tfap 

6/  rfcA 

Oj^  /Ai 

J/\r  &  p 
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II.  INTERVIEW  DATA  COLLECTION 


A. 


B. 


FLIGHT  EXPEREINCE 

1.  Total  hours:  ]?cxO 

2.  Total  hours  (MH-60S)  :  3^ 

3.  Previous  model  qualified  HAC?: 

QUESTIONS 


1.  What  MH-60S  missions  are  you  most  familiar  with 
(SAR,  LOG,  MEDEVAC,  etc) : 


pr1  / 


'o 


2.  Given  you  experience  in  the  above  missions  you 
highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions:  /  i 

~  ((ee'p  s-A  Ctr-  udub?  c  (  ~  / 1  //Y  / 

~h  l i, 

-  k ^  uAr  iG/u  is  m  mi  Wf 

Cfuolo.p  PAl  M?  P  e»kr  c4A. 

£J  w-  ^  H  ^  7Khb  *  H 

What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 

fAo^  Pge b  70  >  ^Ior 


oo 
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Dislikes: 

dou  Id  “f 

pcj, 

-  fat  |W  fo^l 

U  M  •v 


*i4k.  ^ 

^  ,,!/  : .  .t  t"'-'!"' :,/ 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 

-  Y/Mt  bocsd  it,  OxMuffil  -  n  ? 

_  BKc  W  ir^r  u! 

'  <-k*> 


Aia 


f 


i  uL  -/  ^  -  * *~wt  * 

4fo^  Ho^k  GPi  Screen  fr^el  A^Qj-J 

5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 

iWw  Uocfii  at-  dJk**  Sfte. 

1 1 s\c(  5u^  ^QJ 


U>Or\ 


/la  uar, 


4 
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7w,f.  -  fi!r  -A  d"  'few  '*'/  ut  s"r 


jlrfOvl^ 

<  /k^ 

?  Qa 

ffitLC 

■b>(MS\ 

cbiA-T* 

b 

fr&c~ 

rjcM)A\ 

\-o 

beac/r 

uf 

>0 

Cj/W-A 

\j;t^ 

\> 

(a*^  rc> 


l/Y'Orf 


rfftr^t/ 


Ce4o~  b A  AM  /~ ^ 


_>/ 


)ps\CL*'n~^  -*  ^Crobj  <P 


L>dA  'M  ^/e' 

^/o; 


/A*  My^  U^'/S 

lifrt'i^S 

CJ?or  uf  ^ 


-b  -*> 


‘•'7/  A.  ^ 
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II.  INTERVIEW  DATA  COLLECTION 


A.  FLIGHT  EXPEREINCE 

1.  Total  hours:  0O 

2.  Total  hours  (MH-60S)  :  $DO 

3.  Previous  model  qualified  HAC?:  fOo 

B .  QUESTIONS 


1.  What  MH-60S  missions  are  you  most  familiar 
(SAR,  LOG,  MEDEVAC,  etc) : 

SAt  UoG,  1  farce  Cf\r^c( 


with 


2.  Given  you  experience  in  the  above  missions  you 

highlighted,  tell  me  about  instances  for  which  you  may  have 
experienced  difficulties  with  the  cockpit  interface  while 
conducting  those  missions:  ,  j  j  - 

rf.  <f  ,  dO  kd-i  up  ^ 

t  (tyrttt*[dry  rtkdidi)  ~  pads.  M>  t>^ 

fiigUr  b'j  Cklbu  rVlP-J 

3.  What  are  your  general  likes  and  dislikes  with  the 
cockpit  interface? 
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Dislikes : 


r^r  Src<ff~^y 


4.  Are  there  any  other  MH-60S  interface  issues  that  you 
would  like  to  describe  or  may  be  relevant  to  this  study? 


5.  Finally,  if  there  was  something  you  could  change 
about  the  cockpit,  what  would  it  be? 


4 
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